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DISTRIBUTED SNIFFER SYS TEM™ 


PREFACE 


Network 
General 


Preface 


About This Manual 


This manual describes the functions and operations of the Sniffer 
analyzer, a software component of the Distributed Sniffer System™. 


The Distributed Sniffer System consists of two types of products: 
Sniffer® servers and SniffMaster™ consoles. Each server observes the 
local or wide-area network to which it is attached; the consoles control 
the servers and display the results of the servers’ activities. Some 
servers run the monitoring or analysis application alone, while others 
run both. 


Manuals for the Distributed Sniffer System 


Two types of manuals accompany the Distributed Sniffer System. The 
primary manuals, which include this manual, describe the system's 
normal operations; the supplementary manuals describe the 
programs that configure and test the system’s various hardware and 
software components for troubleshooting. Figure ii describes the 
primary manuals that accompany the Distributed Sniffer System. The 
actual manuals in your shipment depend on the configuration of your 
particular system. 


For Information On... Read... 


Installing and configuring the server. | Distributed Sniffer System: 
Installation and Operations Manual 
or Sniffer Server Installation Manual. 


Installing and configuring the 
console. 
Controlling the server from the 
console. 

Starting and terminating the 
applications on the server. 


Operating a server’s monitor Distributed Sniffer System: Token 
functions on a token ring network. | Ring Monitor Operations Manual. 


Distributed Sniffer System: 
Installation and Operations Manual. 


Operating a server's monitor Distributed Sniffer System: Ethernet 
functions on an Ethernet network Monitor Operations Manual. 


Operating a server's analyzer Distributed Sniffer System: Analyzer 
functions on Ethernet, token ring, or a | Operations Manual (this manual) 


WAN/synchronous network 
Various network and protocol types. | Distributed Sniffer System: Network 
and Protocol Reference. 


Figure i. Primary manuals for the Distributed Sniffer System. 
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In addition to the manuals that directly concern the Distributed 
Sniffer System, depending on the network or configuration you are 
using, you may also wish to consult the supplementary manuals 
listed in Figure ii. 


Running the adapter diagnostics to | Token-Ring Network Guide to 
test the IBM 16/4 token ring adapter | Operations. 
in the console. 


Running the diagnostics to test the | NI5210 Installation Manual. 
InterLan NI5210 Ethernet controller 


in the console. 


Configuring and using the IBM® 
Local Area Network (LAN) Support 
Program. 


Local Area Network Support Program, 
version 1.2, User’s Guide. 


Figure it. Supplementary manuals. 


If the product shipment includes release notes or README files on 
disk, the information in the note or file supersedes the information in 
this manual. 


Audience of This Manual 


The manual has been prepared with the following assumptions: 


* You are a network manager or troubleshooter who 
understands your network’s operation. 


¢ You are familiar with DOS. 


* You have properly started the SniffMaster console. 


= 


Organization of This Manual 


Preface 


Figure iv describes this manual’s organization. 


Table of Contents 
List of Figures 
List of Procedures 
Preface 


Chapter 1, “Overview— 
What a Sniffer Analysis 
Server Does.” 


Chapter 2, “Monitoring 
Traffic and Capturing 
Frames.” 


Chapter 3, “Network- 
Specific Testing.” 


Chapter 4, “Generating 
Traffic to Load the 
Network.” 


Chapter 5, “Displaying 
and Interpreting 
Captured Frames.” 


Chapter 6, “The 
Analysis Server's Use of 
Files.” 


Chapter 7, “Protocol 
Interpreter 
Combinations.” 


For many tasks, the manual includes a 
step-by-step procedure; they’re all 
listed in the List of Procedures. 


Provides an overview of the analyzer 
and describes its capabilities. It also 
discusses the menu structure. 


Describes the preparation required 
before you start to capture frames for 
analysis, and what the analyzer 
displays as capture proceeds. 


Describes the cable-test feature of the 
Ethernet analyzer. 


Describes the traffic generator for 
Ethernet and token ring networks. 


Describes the procedures for filtering, 
interpreting, and displaying captured 
frames. 


Describes the server’s directory 
structure and the types and formats of 
files it uses. 


Describes the procedure to generate 
Sniffer analyzers with alternative 
combinations of protocol interpreters. 


Figure iv. Outline of this manual 


Navigational Aids Used in This Manual 


To help you find procedures easily, a separate list of procedures is 
provided in this manual in addition to the Table of Contents and List 
of Figures. To facilitate use of this manual as a reference, there is an 


extensive index. 
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This manual uses icons in the margin to help you locate important 
information as explained below: 


The paragraph next to this icon contains information that is especially 
important; you should be certain to read it carefully before you 
proceed. 


A warning gives you instructions that you must follow to avoid 
possible damage to uata files, program files, or hardware devices. 


A cautionary paragraph provides information that may help you 
avoid a possible pitfall or misunderstanding. 


A recommendation describes a useful and valuable way of using the 
product. 


eee 


\\ 
oy 


JK A procedure is a series of steps for accomplishing a particular task. 


NOY 
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Conventions Used in This Manual 


Special Notations 
The following describes the conventions used in this manual: 
Bold Menu options are in bold type. For example: 
Move the highlight to Display and press Enter. 


UPPERCASE The filenames and command names you type at a DOS 
prompt are in uppercase. For example: 


Names are recorded in the file STARTUP.xxD. 


Bolditalics Variables, for which you insert values, are in bold 
italics. For example: 


Type the number of minutes and seconds in mm:ss 
format. 


Screen font Screen messages are printed in monospaced font. For 
example: 


If a monitoring session is in progress, the following 
message appears: 


You must stop monitoring before you can use this feature, 


Terminology 


Hexadecimal numbers mentioned in the manual are followed by 
“(hex)”; numbers without any notations are decimal. For example, 
“The maximum number of stations is 75. The default memory address 
is D8000 (hex).” 
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Preface 


The terms “Sniffer monitor” and “Sniffer analyzer” refer to software 
applications running of the Sniffer server. The term “SniffMaster 
console” refers to a software application running on dedicated PC, at 
which you enter all input and receive all output from the server. 


Screen Displays and Keyboard Input 


All the keystrokes mentioned in the manual are entered from the 
keyboard of the SniffMaster console. Similarly, all the screen displays 
generated by the monitor appear on the console’s screen. 


The screen displays in this manual may not be exactly the same as 
what you see on your console screen. For example, you can choose to 
have the console show the server name on each monitor display, but 
the screens in this manual do not generally show the name. 


Other Sources of Information 


On-Line Help 


Other Manuals 


Tutorial 


Network General Corporation (NGC) provides other sources of 
information that can help you get familiar with the distributed Sniffer 
system. 


After highlighting an item in a console, analyzer, or monitor menu, 
you can see a phrase or sentence in a panel near the bottom of the 
screen. It explains the meaning of the highlighted item. 


If you want to obtain general information ona particular feature of the 
Distributed Sniffer System, press F1 at any time. A dialog box 
containing a list of topics opens. If you are displaying a monitor 
statistics screen, pressing F1 gives you information on the current 
screen. 


This manual does not describe the characteristics of different protocol 
and network types. For general information on these topics, refer to 
Distributed Sniffer System: Network and Protocol Reference. 


NGC distributes a booklet with accompanying diskette entitled Real 
Networks. Real Problems. It presents case studies based on data 
captured with a Sniffer network analyzer from four different 
networks. The Sniffer analyzer and the server's analysis application 
have different capabilities, but the case studies allow you to see how 
investigation of a network problem proceeds. 
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Technical Support 


XX 


You can obtain the tutorial free of charge from any of the company’s 
sales representatives or directly from NGC. 


The procedure for obtaining technical support for problems with the 
Distributed Sniffer System is described in Appendix A of Distributed 
Sniffer System: Installation and Operations Manual. 
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CHAPTER ONE: OVERVIEW—WHAT A SNIFFER ANALYSIS SERVER DOES 1 


General 


Chapter 1. Overview—What a Sniffer 
Analysis Server Does 


Chapter Overview 


This chapter provides a general orientation to the Sniffer analysis 
server. It is aimed mainly at the reader who hasn't yet used a Sniffer 
analyzer. The chapter starts with a general description of the 
distributed analysis system and its four types of components: 
SniffMaster consoles, Sniffer monitor servers, Sniffer analysis servers, and 
Sniffer combined monitoring and analysis servers (combining the 
functions of monitoring and analysis in a single server). 


Each server has two channels, one for monitoring the network being 
studied, the other for transporting data and commands between the 
server and the console. The server is a passive observer of a local area 
network (LAN) or of the synchronous link of a wide area network 
(WAN). 


The chapter depicts the organization of a server's analysis functions by 
a map of the way information flows between them and back to the 
console. Analysis has two main phases: capture (when frames are 
recorded in a storage buffer), followed by analysis (when the captured 
frames are interpreted and displayed). Capture can occur live from the 
network, or as a replay of previously captured data. 


Before capture starts you can set filters to avoid filling the buffer with 
extraneous traffic. You can set a trigger pattern that causes the server 
to stop capture when it has found the condition you specify. While 
capture proceeds, you have a choice of tabular or graphic displays 
that indicate the density of traffic. 


Analysis follows capture. The captured frames are displayed in three 
formats: summary, detail, and hex. Frames and their embedded 
messages are interpreted at each level. Addresses within the frames 
are interpreted from a table of symbolic names. You can filter the 
display, or search through it. 


Because protocol interpreters are so numerous and so large, it’s 
impossible (and unnecessary) to install all of them at once. Each 
analyzer is initially built with two combinations of protocol 
interpreters. The configuration utility lets you construct other 
combinations as you wish. 


The Distributed Sniffer System 


The Sniffer analysis server whose operations are described in this 
manual is one of the three principal components of the Distributed 
Sniffer System. For a perspective on the entire system and the role of 
the SniffMaster console in controlling it, see the companion 
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publication, Distributed Sniffer System: Installation and Operations 
Manual. 


The Role of the Analyzer 


An analyzer —that is, the network analyzer program installed in a 
Sniffer analysis server— records and interprets network 
transmissions. The work of analysis occurs in two main stages: 


Capture The analyzer records network traffic for later 
interpretation. Capture can be filtered to record only traffic 
meeting certain criteria. Capture can be frozen when a 
triggering condition is observed. This assures that the 
retained sample includes traffic just before or after the 
event of interest. 


While capturing frames, the analyzer software maintains 
graphs or tables that summarize the traffic it has recorded.! 


Display The analyzer interprets the recorded traffic. During 
display, the analyzer decodes the various layers of protocol 
in the recorded frames and displays them as English 
abbreviations or summaries. The analyzer can filter the 
display to show only those frames that meet certain criteria. 


The Analyzer as (Mostly) Passive Observer 


A Sniffer server “hears” all traffic that passes through the segment it 
is monitoring. On a WAN/synchronous link, it hears traffic in both 
directions (“from DTE” and “from DCE”). On a LAN, it hears all 
traffic that passes through the segment or subnet that it is monitoring. 
It is characteristic of a LAN that every station physically receives 
every transmission. Ordinarily, each ignores all messages except 
those addressed to it. The Sniffer server not only hears all 
transmissions but, while in “capture” mode, can record them, 
regardless of how they’re addressed. 


In general, the Sniffer server observes, tabulates, or captures, but 
contributes nothing of its own to traffic on the network it is 
monitoring. However, when a server is monitoring a LAN, the server 
may contribute to the LAN’s traffic as follows: 


* On Ethernet or token ring, an analysis server can generate test 
frames. In that mode, it repeatedly transmits a single test 
packet you have specified. 


* On Ethernet, the server can emit a pulse to test for cable defects. 
1. The analyzer’s displays during capture resemble some of the displays produced oe the 


monitor server. Don’t confuse this mini-monitoring during capture with the full-blown 
monitor server, which is quite separate. 
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A Map of the Analyzer’s Functions 


On Ethernet or token ring, if the Sniffer server is configured so 
that its control link is to the same network segment that it is 
monitoring, the monitor channel can hear and capture the 
server's own control messages. In this circumstance, the server 
is taking part in the traffic that it is monitoring. 


On token ring, every station must participate in the ring by 
forwarding traffic from its upstream neighbor to its 
downstream neighbor. Each Sniffer server does that in the 
same way as Other stations. However, the server does not reply 
to the poll for standby monitors, and never acts as the ring’s 
active monitor. It is thus invisible to most other stations. 


On token ring, the server periodically transmits a frame 
addressed to “LAN Manager” announcing “trace tool present.” 
The LAN Manager can force such a station to leave the ring 
immediately. 


On Ethernet or token ring, the server’s transport card may be 
connected to the same network segment or ring as the server's 
monitor card. In that case, the server’s monitor card observes 
the server’s own transport activities. The transport activities 
rarely amount to more than a small percentage of network 
utilization. They use a higher-level protocol called NGCP. If 
you wish, you can set display filters to include or exclude them. 


A Map of the Analyzer’s Functions 


The analyzer’s activities are divided into the set of functions described 
below. The diagram in Figure 1-1 represents schematically the route 
by which information flows from between the various parts. 
Following the paths that frames may follow as they are captured from 
the network, the analyzer’s principal components are as follows: 


Capture filter: it decides which arriving frames to discard and 
which to retain. 


Capture displays: these chart the progress of capture. 


Trigger detector: it scans arriving frames for a pattern. When it 
detects the pattern, it stops capture so that frames preceding or 
following the trigger event are retained. 


Capture buffer: this is a storage area for frames that have been 
accepted. From here they are subsequently interpreted and 
displayed. 


Protocol interpreters: these identify the protocols nested within 
each frame and interpret their contents. 


Display filters: these select from the capture buffer the frames 
that will be displayed. 
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* Display of the selected frames in three modes: 
— Summary 
— Detail 
— Hex with ASCII or EBCDIC 
* Output of the display 
— Transmitted to the console screen 
— Saved to a disk file on the server 
— Sent toa printer 
Figure 1-1 represents the route that frames follow as they move from 
the network to the network interface card, from there through filters 
and triggers to the capture buffer, and from there to the interpreters 


and displays. You may want to turn back to the figure as you read 
descriptions of these functions in the sections that follow. 
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A Map of the Analyzer’s Functions 
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Figure 1-1. Schematic view of the flow of frames in the Sniffer analyzer. 
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Capturing Traffic 


The analysis server scrutinizes the traffic it hears and records the 
frames that pass various filters. Recorded frames may be saved to a 
file for analysis later, or immediately displayed, filtered, and 
interpreted. 


Sources of Capture— Live vs. Recorded 


Live capture 


Before the Sniffer analyzer can provide detailed interpretation or 
analysis, it must obtain a sample of network traffic. There are two 
ways to do this: 


* Live capture, or 


* Capture from a previously recorded file 


The Sniffer analysis server's network interface card detects all traffic, 
and passes it to the analysis server’s CPU. Frames that pass the 
capture filter are stored in the capture buffer for subsequent display 
or analysis. As frames arrive, the analysis server updates its real-time 
display of traffic density. 


Capture from a previously recorded file 


Instead of capturing from the network, the Sniffer analyzer can read 
from a file of saved frames. Such a file is created by saving the 
contents of the capture buffer. By capturing from a file, you can 
“replay” a capture that took place at an earlier time. Since a file of 
captured frames includes a timestamp for each frame, the replayed 
capture reproduces not only the data but also the timing of each 
frame’s arrival. 


When you're capturing from a previously recorded file, you can set 
capture filters just as you would for live capture, accepting into the 
capture buffer only those frames that pass the filter. Capturing from a 
file is a way to gain experience in operating the analysis server or 
setting its capture filters. You can replay recorded captures even 
when the network that the server monitors is not active or the server's 
“monitor” card is not connected. 


Filters to Select Frames for Capture 


The number of frames reaching the adapter is potentially so large that 
it’s often essential to select only a subset for storage. Saving them all 
would take far too much space. Before you start capture, you can set 
filters so that the analysis server saves only frames that meet certain 
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Capturing Traffic 


criteria. The analysis server applies a filter to each newly-arrived 
frame and discards all frames that do not meet the test. 


Capture filters may be any combination of the following types. In each 
case, the filter can be set to save frames that meet the test or those that 
don’t. 


Station address The Sniffer analyzer accepts frames sent to or 
from particular addresses that you specify.! 


Destination class _ The Sniffer analyzer accepts frames that have 
specific destinations, rather than frames 
addressed to a group (for example, broadcast). 


Unknown station The Sniffer analyzer accepts frames sent from or 
to an “unknown” station— that is, a station not 
included in the table of names for stations. 


Protocol The analyzer accepts frames that contain any of 
the low-level protocols you specify. (During 
capture, to maintain speed, filtering is restricted 
to the lower levels. During display, you can set 
filters for higher level protocols embedded 
within the frames.) 


Pattern The Sniffer analyzer accepts frames that contain 
a specified pattern. A pattern can be constructed 
as some logical combination of up to eight 
component patterns. Each of the component 
patterns is described by a particular sequence of 
bits or characters at specified positions. For 
example, a filter might accept only frames that 
pass between a particular user and server and 
involve a particular error code in a particular 
protocol. 


Displays During Capture 


While it is capturing frames, the Sniffer analyzer is able to tabulate 
and meter the frames it is capturing. The tabulations in some ways 
resemble those provided by the Sniffer monitor, a separate software 
module available for Ethernet and token ring, routinely installed on 
each analysis server for those networks. However, the Sniffer monitor 
doesn’t save frames for later analysis and doesn’t interpret their 
protocols. When your interest is primarily monitoring, you may find 
it preferable to run the Sniffer monitor rather than the Sniffer 
analyzer. You invoke the monitor functions from the main selection 
menu (see Figure 1-6, page 1-22). 


1. During capture, you can only filter on DLC addresses. During display, you can filter both 
by address level or on specific high-level addresses. 


i 
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Traffic Density Displays 


What follows describes the more limited facilities for metering and 
tabulation that accompany the capture phase of the Sniffer analyzer. 


Before you start capture, select the type of display the Sniffer analyzer 
will be generating while frames arrive. The choices are: 


Graphic “Skyline” displays of traffic density over time. 
Tabular Source or source-and-destination counts in various 
formats. 


Highspeed On Ethernet, this option suppresses displays during 
capture to let the analyzer give full attention to 
arriving traffic. 


While it “listens” to network traffic, the analysis server accumulates 
statistics. As frames arrive, it either displays real-time graphs of traffic 
density, or updates a table that counts messages by source and 
destination. An example of a traffic density graph is shown in Figure 
1-2. A new column is added at the right once every second, minute, 
or hour, depending on the time scale you select. 


CAPTURING 00:01:33 


1008 


frames 
NOW 


ragments isaligne 
6284 eel accepted 1185 Kbytes accepted 


mes = secon 
2Select 4 Clear} o. Scaleml6 cae View 98 View 18 Stop 
display scree! up down flearlier§ later — capture 


Figure 1-2. Skyline view of traffic density at one-second intervals. 


The display shows two histograms, one above another. Ona 
synchronous link, the display shows histograms for traffic from DTE 
and from DCE. Ona LAN, one shows traffic density (frames or 
kilobytes per second) and a second the number of stations that are 
active (have transmitted during the time interval). 


Source and Destination Tables During Capture 


The Capture Buffer 


Capturing Traffic 


Asan alternative to the “skyline” histograms, the analyzer can instead 
tabulate the frames as it accepts them, with separate counters for each 
source-and-destination pair. 
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4 Harry 
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190% Buffer utilization 


169 1020 3 
Frames per second 


00 
4 Clear} 9 18 Stop 
scree Pausefmcapture 
Figure 1-3. Source-and-destination pair count during capture. 


During capture, traffic on a LAN is subtotaled by station, either 
individually by source, or pairwise by source and destination. Figure 
1-2 shows a tabulation by source and destination. On a synchronous 
link, counts are subtotaled by type of frame and also by higher-level 
address (logical call number). There are separate counts for traffic 
from DTE and from DCE. 


Frames that are accepted move to the capture buffer. The capture 
buffer is a large block of the server’s main memory. The exact amount 
varies with the amount of RAM installed in the server and the amount 
reserved by the server and analyzer software. The capacity ranges 
from a few thousand medium-sized frames, up to many thousands. 
Where space is at a premium or frames are long, you can save space 
by truncating frames that exceed a given length. 


Frames accumulate in the capture buffer in the order they are 
received. When the capture buffer becomes full, the Sniffer analyzer 
can halt capture or it can discard older frames to make way for new 
arrivals. 


Allanalysis and interpretation is done on frames in the capture buffer. 
While the buffer has substantial space —room for thousands of 
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captured frames— it is still very small compared to the volume of 
traffic on a network. That’s why it’s essential to restrict the buffer to 
frames that are relevant. There are two main ways to do this: 


* Accepting frames selectively, so that the buffer isn’t flooded 
with irrelevant frames. This is done by the capture filters 
command (described in the preceding sections). 


* Timing the end of capture so that the frames that interest you 
are still in the buffer. This is done by the trigger pattern detector 
(described in the next section). 


Stopping Capture When a “Trigger” Pattern Occurs 


To be sure that the frames that interest you are retained in the capture 
buffer, you can set a detector that freezes capture when it sees a frame 
containing a pattern you've specified. The detector scans the stream of 
incoming frames after they’ ve passed the capture filters but before they 
go to the capture buffer. (See Figure 1-1, page 1-7). 


When it finds the trigger pattern, the detector stops capture. You can 
examine the frames in the buffer to see what has happened. You can 
have the detector stop capture immediately or after some delay. 
Setting a delay lets the server retain frames that follow the trigger 
event, as well as frames that precede it. 


A trigger pattern is some combination of bits, bytes or characters at 
various positions in a frame. A trigger can be constructed as a logical 
combination of up to eight component patterns, each described by a 
particular sequence at specified positions. 


To illustrate use of a trigger pattern, suppose it appears that there are 
intermittent difficulties with access to a file server. A filter could 
restrict capture to frames to or from the server. A trigger pattern could 
be set to halt capture when a frame from the server contains an error 
code in a protocol related to file transfer. When the analysis server 
reports such a frame, you have both a record of the error report and of 
the sequence of events that led to it. 


Alternatives When Capture Is Complete 


Once capture has stopped, you can: 


* Copy the contents of the capture buffer to a file for later 
analysis or display. 


* Filter the display, so you see only those frames that meet 
certain criteria. 


* View the frames through one or more views, each with a 
particular style of display. 


* Browse through the frames in the capture buffer. 


Interpreting What You’ve Captured 


* Print the contents of the buffer, according to the filters and 
views you've specified. 


You have many options for displaying the contents of the capture 
buffer, either on the SniffMaster screen or ina printed report. (You can 
direct output either to a printer or to a file. The printer may be 
attached to the server or to the console; the file must be on the Sniffer 
server's hard disk (but can then be uploaded to the SniffMaster 
console if you wish). 


You can set up a display filter so that frames that don’t interest you 
are omitted from the display (even though they remain in the capture 
buffer). The mechanism for filtering frames from the display is like the 
mechanism for filtering frames during capture. 


Saving the Capture Buffer 


From the keyboard, you can select a command that saves the contents 
of the capture buffer to a file. You can save the entire capture buffer or 
just the frames that are accepted by your current display filter. 


Once you have saved the capture buffer to a file, you can: 
* Load the capture buffer with the saved file. 


* Capture from the saved file— that is, re-enact the original 
capture. 


Either procedure restores the capture buffer to the way it was when 
you saved it (but without frames that you excluded at the time you 
saved). 


Interpreting What You’ve Captured 


The Sniffer analyzer takes what would otherwise be a dense and 
meaningless stream of bits and translates it into readable English. It 
dissects each transmission (called a frame or packet) into its 
component layers. Then it decodes each layer according to its 
protocol—the rules of format and syntax that govern its encoding. For 
a quick summary view, the analysis server can show you just the 
highest layer of interpretation for each embedded packet. Or, if you 
request, it can show you all layers from lowest to highest. For each 
layer, the interpreter can show a succinct one-line summary, or a 
detailed translation of the important fields and parameters. 


Protocol Interpreter Suites 


The Sniffer analyzer doesn’t just capture and store frames from the 
network. It also interprets them. When you select the detail view, you 
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get a set of interpretations for each frame, one interpretation for each 
level of protocol that the frame contains. 


Interpretation of the lowest-level protocols is provided automatically 
when you specify the network to which your Sniffer analysis server 
will be attached. Separate protocol interpreter suites interpret higher- 
level protocols. Each suite provides interpretation of several protocols 
likely to occur together. Figure 1-5 shows a list of the protocol 
interpreter suites available when this manual was printed; it’s on page 
1-21 (with the discussion of alternate configurations). 


Each analysis server has all of Network General's current protocol 
interpreter suites. However, only a subset is enabled at one time (see 
“Configuring Alternative Sets of Protocol Interpreters” on page 1-20). 


Symbolic Names for Addresses 


To make its displays easier to read, the interpreter augments the 
binary codes that identify sender, receiver, or routing with symbolic 
entries from a name table. Thus, when a packet's high-level 
destination is 00100100001101010000000011000011, rather than 
showing the address as 24 35 00 C3 or even [36.53.0.195], the analysis 
server lets you see it as “Janet’s Workstation” or whatever name 
makes sense to you. When the analysis server has no name for a 
station, it displays the name of the manufacturer and the unique 
address that the manufacturer assigns to that station. 


Names and Name Tables 


A name table pairs a numeric network address with an arbitrary name. 
When the Sniffer analyzer identifies a station, it can substitute the 
name in the table for the numeric code that the server actually 
received. 


The first time you display frames after a new capture, the analysis 
server checks through all of the frames in the capture buffer and adds 
to its working copy of the name table any DLC addresses that are not 
yet in it. You can edit the working table to provide symbolic 
equivalents for the addresses that lack them. You can also save the 
working name table and reuse it during subsequent captures or 
displays. 


After you have provided symbolic equivalents, the analysis server 
uses them not only in displays but also during subsequent capture 
sessions. The Sniffer monitor shares tables with the Sniffer analyzer, 
so that they both benefit from additions to the name table. 


Resolving Names from Other Tables 


The manage names menu contains an instruction to resolve names. 
When you select this option, the analysis server searches a saved 
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Searching for Names 


Interpreting What You’ve Captured 


name table to find equivalents for addresses that are not yet named in 
the analyzer’s working name table. 


In some network protocols (for example, NetBIOS, AppleTalk or 
Novell NetWare), stations may declare names for themselves. The 
Sniffer analyzer is able to search the capture buffer for frames that 
contain names and use the names it finds to fill blanks in the working 
name table. 


Saving and Restoring Setups 


The Sniffer network analyzer offers a rich choice of options 
concerning both capture and display. To simplify work at subsequent 
sessions, you can name and store a record of the options you've 
selected. That's called a setup file. At a subsequent session, you have 
only to load a previously-saved setup, and all the settings it contains 
are restored. 


Three Ways to View the Captured Frames 


The Sniffer analyzer offers three levels of interpretation: 


Summary A one-line summary of the highest level of protocol in 
each frame, or, if you wish, of each of the various 
levels each frame contains. 


Detail A detailed English translation of all fields and 
parameters within the frame. 


Hexadecimal Exact record of the transmitted data, with ASCII or 
EBCDIC transliteration, as appropriate. 
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Detail view 


Summary view 


Hexadecimal view 


SUMMARY—Delta T—-DST————SRC 
56 8.6014 Kate «BIZ-ONE DLC 882.2 size=38 bytes 
XNS NetWare Reply N=204 C=45 T=0 
NCP R OK 


57 6.6809 BIZ-ONE «Kate DLC 882.2 size=44 bytes 
XNS NetWare Request N=2@5 C=45 T 


DETAIL: 
Packet type = 17 (Novell NetWare) 


0238 00 00 02 20 B0 20 23 59 BA B5 83 26 
Frame 56 of 7151 


Use TAB to select windows 
1 2 Set 4 Zoom 6Displug/ Prevgli8 Next 10 New 
Help § mark in [i Menusimmoptions™ framefi frame capture} 


Figure 1-4. Three views in display of a captured frame. 


In Figure 1-4, all three views are visible: summary, detail, and hex. 


Each frame is decoded to show the type of frame and the protocols it 
contains. For high-level frames, the interpretation may require several 
levels, one for each protocol the frame contains. For each protocol, the 
detail view names the principal fields and interprets the values of 
each. 


For each address in each protocol, the detail view shows both the 
numeric code actually transmitted and a symbolic equivalent. You 
can edit the address table to insert your own names, or import names 
from an external file. 


This condensed form abbreviates and truncates some of the 
information from the detail view. 


All-level vs. highest-level-only display 


You can elect to display a one-line summary of each protocol within a 
frame, or to show only the highest level. 


The entire frame is listed. You can elect to have character data 
displayed according to ASCII or EBCDIC conventions. 


Interpreting What You’ve Captured 


The hexadecimal view and the detail view show data for just one 
frame. The summary view shows not only the frame you are 
examining but a few on either side of it as well for context. 


Distinguishing Protocol Layers 


Coordination of views 


Two-Station Format 


Views and Viewports 


Two viewports 


The interpreter labels and decodes the standard fields in each frame, 
making it easy to see the message conveyed. At the SniffMaster 
console, each layer is shown in a distinctive color (except, of course, 
when you equip the console with a monochrome display). Color 
coding applies in all three views: summary, detail, and hex. 


When you open two or more views at once, the Sniffer analyzer 
coordinates highlighting in the various views. The detail view’s 
interpretation is automatically scrolled to match the level you've 
highlighted in the summary view. When both the detail and hex 
views are open, moving the highlight in the detail view produces a 
corresponding highlight in the hex view, so you can see which parts 
of the hex display correspond to the interpreted detail. 


Frequently, analysis concerns the flow of commands between a pair 
of stations. Two-station format is a variant form of the summary view. 
Frames from the first station are summarized on the left side of the 
screen, and frames from the second station are summarized on the 
right. That way, it’s easy to distinguish the two sides of a 
conversation. (If you also accept frames from other stations, they 
remain in the normal full-width format.) 


Each view you select appears in its own rectangle within the 
displayed screen. The screen may be tiled as one, two, three, four, or 
six equal-sized rectangles, according to the number of views and 
viewports you request. 


Sometimes it’s important to compare a frame from one part of the 
capture buffer with a frame that arrived earlier or later. You can do 
that by electing two viewports. That splits the screen into left and 
right halves. You can scroll the two sides independently, permitting 
you to display one frame on the left and another on the right. 
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Scroll 


Zoom 


When a frame’s display doesn’t fit within its panel, you can scroll the 
active panel both vertically and horizontally until the part you want 
is in view. 


You can temporarily assign one view to the entire Sniffer display. To 
do that, press F4, labeled zoom. The active view gets the entire display 
area until you again press F4 to “zoom out,” thereby restoring the 
other views. 


Filtering and Searching During Display 


During display, you can use filters to select frames from the capture 

buffer. They're called display filters; they work in much the same way 
as capture filters. However, they can also respond to criteria that are 
not feasible during capture. For example, they can choose to display 

only frames that contain a particular high-level protocol or high-level 
address. 


Filtering permits you to suppress traffic that’s irrelevant to your 
concern, and to limit the display to frames involved in a particular 
transaction. With the obscuring bulk cleared away and the remaining 
frames concisely interpreted, it becomes easy to trace interactions 
between stations. You can see normal patterns at a glance, and readily 
identify suspicious exceptions. 


It’s also possible to search through the captured frames for those that 
contain particular items. This feature not only permits you to search 
for a particular address or pattern of data, but also for text that the 
Sniffer analyzer uses in the interpretation. Thus, you can search for 
names, values, or phrases. Frequently, the text you search for is 
implied by codes contained in the frame, but present as characters 
only in the Sniffer analyzer’s interpretation. 


Low and High-Level Filtering 


Display filters work in much the same way as capture filters. 
However, because display filters don’t have to work under time- 
pressure, they can also examine higher-level protocols and higher- 
level addressing. The list of protocols is longer in the display filters 
menu than in the capture filters menu. For display filters, the list 
includes all the protocols that your protocol interpreter suites can 
recognize. 


Higher Level Addresses 


Address Level Filtering 


Interpreting What You’ve Captured 


In addition to the DLC source and destination addresses, a frame may 
contain packets that have their own, higher-level addresses. The 
interpreters display the higher level addresses and interpret them 
according to a name table that you can edit as you find convenient. 


During display (although not during capture) you can set filters for 
specific higher-level addresses. 


An address level filter lets you accept frames only if they include an 
address at a particular protocol. When you set an address level filter, 
you check the various levels that you wish to include. A frame is 
accepted if one or more of the levels you checked is represented in its 
addressing (or in the addressing of an embedded packet). 


For example, on an Ethernet network using NetBIOS, every frame has 
a DLC address. Some frames also have a NetBIOS address. In the 
address level filter, if you put a check mark beside DLC, the filter 
accepts every frame, since every frame has a DLC address. However, 
if you check NetBIOS but not DLC, the filter accepts only those frames 
that contain a NetBIOS address. 


In the summary view, the analysis server shows each frame's address 
at the highest of the levels you checked. 


Searching for Patterns in the Displayed Frames 


You can search through the displayed frames for patterns, or 
combinations of patterns. Patterns are described in the same way as 
capture filters (page 1-8) or the trigger pattern that stops capture 
(page 1-12). 


Searching for Text that Appears 
In Any of the Three Views 


You can search through the capture buffer for a frame whose display 
contains a particular piece of text. Notice that the search is not limited 
to data actually present in the frame itself, but can also be for text that 
occurs in the summary or detail display that the analyzer generates 
when it describes the frame. This means that you could search for a 
symbolic address even though the name you look for is one you 
invented yourself and occurs nowhere in the transmission. Or you 
could look for a phrase used by the interpreter to describe the 
meaning of a code (for example, “file busy” or “access denied”) even 
though the frame itself contains only a numeric value at a particular 
position. 
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Configuring Alternative Sets of Protocol Interpreters 


Each Sniffer analysis server's software is compiled at the factory to 
match the type of network it will monitor (Ethernet, token ring, or 
WAN/synchronous). The software is also specific to the network and 
protocol stack that the analyzer will use to transport data and control 
information between the server and the console. 


Each Sniffer analysis server contains copies of all current Network 
General protocol interpreter suites. 


It is most unlikely that you would ever need all of the protocol 
interpreter suites at once. Moreover, the protocol interpreter suites are 
so large and so numerous that there isn’t room for all of them at once 
in a single executable file. The factory therefore supplies two versions 
of the program called Sniffer Network Analyzer. You'll see two 
entries for Analyzer in the selection menu (Figure 1-6). (They’ll all say 
Ethernet Analyzer, Token Ring Analyzer or WAN/Synchronous 
Analyzer, as appropriate.) 


Between them, the two versions of the Sniffer analyzer contain all the 
protocol interpreter suites. Some interpreter suites are in one analyzer 
program, some in the other, and some in both. The division into two 
overlapping sets of protocol interpreters is initially provided at the 
factory. If you subsequently prefer other combinations of protocols, 
the Sniffer Configuration Utility (described in Chapter 7) makes it 
easy to generate them. 


Identifying the Protocol Suites in a Particular Analyzer 


When you highlight one of the “Analyzer” entries in the server’s main 
selection menu, in the menu’s lower panel you'll see a list of its 
protocol interpreter suites. That lets you distinguish between various 
Analyzers listed in the menu. (You can see the Analyzer protocol 
interpreter suites in the lower panel of Figure 1-6). 
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Suite Name Protocols 


1301 IBM SNA, SMB (including OS/2 LAN Manager), RPL, NetBIOS, IBMNM, 
SNAP, SDLC, LLC (802.2), MAC. 


1302 Novell NetWare NCP, SAP, NetBIOS, XNS, SPX, IPX, RIP, Echo, Error, AFRP, SNAP, 


LLC (802.2). 

1303 XNS SMB (including OS/2 LAN Manager), NBP, XNS, Courier, SPP, IDP, 
PEP, RIP, Echo, Error, SNAP, LLC (802.2). 

1304 TCP/IP SMB (including OS/2 LAN Manager), SNMP, Telnet, FIP, TFTP, 


SMTP, RUNIX, CMOT, DNS, TCP, UDP, IP, GGP, ARP, RARP, SNAP, 
TRLR, RIP, NetBIOS, ICMP, LLC (802.2), ASN.1. 


1305 Sun ND, NFS, YP, PMAP, Mount, RPC. 


1306 ISO X.400, FTAM (8571/4), VTP (9041), ACSE (8650/2), ISO Presentation 
(8823), ISO NetBIOS (MAP/TOP 3.0), ISO Session (8327), SMB 
(including OS/2 LAN Manager), TP (8073, class 0, 2, 4), CLNS (8473), 
ES-IS Routing (9542), SNAP, LLC (8802/2, type 1 and type 2), ISODE, 


ASN.1. 

1307. DECnet DAP, LAT, NICE, SMB, CTERM, FOUND, SCP, NSP, DRP, MOP, 
SNAP, LLC (802.2). 

1308 Nestar Nestar FS and IOB commands; SMB; XNS; SPP; IDP; FRP. 


1309 Banyan VINES _ StreetTalk, Mail, Route, Echo, Matchmaker, IPC, SMB, SPP, RTP, 
ARP, ICP, IP, FRP, SNAP, LLC (802.2). 


1310 AppleTalk AFP, TOPS, PAP, ASP, SoftTalk, ADSP, NBP, ATP, RTMP, ZIP, Echo, 
KSP, AARP, DDP, SNAP, LLC (802.2), LAP. 


1311 X Windows X Windows version 11, release 4. 


1312 X.25 PAD (X.3, X.28, X.29), QLLC, SNDCP, X.25 layer 3, PPP, HDLC, 
SNAP, LLC (802.2). 


Figure 1-5. Protocol Interpreter Suites. 


The Analyzer’s Menus and Controls 


While you operate a Sniffer analyzer, you're always working from a 
SniffMaster console. There are menus to operate the console and 
menus to operate the individual servers. From the SniffMaster console 
menus, you activate the connection to one or more servers. 


What You See When You Connect to a Server 


When you display a server's screen, you've tuned in to what the 
server is doing at the moment. The server has a life of its own. It was 
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running before you connected to it. It will go on running after you 
disconnect from it. It goes on running whether or not you choose to 
show its screen at your console. (You might think of this as coming 
into a room in which the server has previously been running with no 
one watching, but—now that you’re in the room with it—you may 
choose to look at its screen.) 


If the analysis server has been collecting data unattended, you see the 
display that was last requested, updated to show the current 
situation. If the analysis server has been started but given no specific 
instructions, you see its initial selection menu. If an earlier instruction 
exited from the server's menus and returned to DOS, you see the DOS 
prompt. 


The Server’s Selection Menu 


When the analysis server is newly installed, or whenever it has just 
been reset or powered up, upon connection you'll see its main selection 
menu. From the selection menu, you can tell the server to run the 
Sniffer monitor or one of the Sniffer analyzers. You may also select the 
file transfer utility or to configure the server. 


You can see an example in Figure 1-8. The selection menu lists the 
major choices open to you. (The items in the menu depend on the 

software modules and protocol interpreter suites installed in your 
particular Sniffer server.) 


tn 
Sniffer Server 
(C) Copyright 1989-1991, Network General Corporation 


Ethernet Monitor File Transfer Utility 
Ethernet Analyzer Configure Server 


Ethernet Analyzer Exit to the Operating System 


Suites: TCP/IP, SUN, DECnet, Banyan, AppleTalk, XWindows 


——Use arrow keys to select, then press Enter. 


Figure 1-6. Selection menu shows protocol interpreter suites for the 
highlighted analyzer 
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In each menu, one item is highlighted.! The lower portion of the panel 
contains a brief explanation of the highlighted entry. Pressing one of 
the cursor keys moves the highlight to another entry. To execute the 
entry that’s highlighted, press Enter. 


KAS To start an analyzer 


1. From the SniffMaster console, connect to a server. (For details 
regarding this step at the console, see Distributed Sniffer System: 
Installation and Operations Manual). 


Result: You see the server's current screen. When the server has 
been newly installed or has been reset, you'll see its main 
selection menu. 


2. Inthe server’s main selection menu, move the highlight to the 
analyzer you want and press Enter. (As you move the highlight 
to each analyzer, the list of its protocol interpreters appears in 
the menu’s lower panel.) 


Other Choices in the Server’s Selection Menu 


Some entries are always present in the main selection menu. For 
example, the menu always includes the option to exit to the operating 
system. The possible selections and the actions they perform are listed 
in Figure 1-7. 


1. Weuse “highlight” to mean the distinctive display of the selected item at the center of the 
screen. Depending on the type of display you're using, this may be in a contrasting color, 
or flashing or in reverse video. 


lias 
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Selection Action 


xx Monitor Starts the Sniffer monitor on the server, and 
passes control to the monitor’s main menu. 


xx Analyzer Starts the Sniffer analyzer on the server, and 
passes control to the analyzer’s main menu. 
(The lower panel lists that analyzer’s protocol 
suites.) 


(initially, two of 
them in the menu) 


File Transfer Starts the server’s end of the file transfer. 
Utility When you invoke the corresponding utility at 
the console, you can transfer a file between 
them. For details, see Distributed Sniffer System: 
Installation and Operations Manual. 


Configure Server Brings up a menu in which you may elect: 


* To set server parameters. For details, see 
Distributed Sniffer System: Installation and 
Operations Manual. 


To create (or delete) analyzers with 
particular combinations of protocol 
interpreter suites. For details, see Chapter 


Exit to the Exits from the selection menu and returns to a 
Operating subset of the DOS operating system. (The 
System server is now inactive as an analyzer. If it was 

previously running the monitor and you did 
not explicitly shut down the monitor, the 
monitor continues to run in the background). 


To restart the menu, at the DOS prompt type 
menu. 


Figure 1-7. Effect of items in the analysis server's main selection menu. 


Connecting When the Analyzer or the Monitor is Already Running 


When your console starts displaying the server's screen, you may find 
that the Sniffer analyzer is already running. (Or, on Ethernet or token 
ring, the Sniffer monitor may be already running.) If so, instead of the 
server's opening selection menu, you may immediately see a display 
from the analyzer (or the monitor, as the case may be). 


If the server has been configured to accept more that one console, it’s 
possible that, when you start your session, someone else is already 
connected from another console. Or some one else may connect to the 
same server later in your session. 


When two consoles are connected to the same server, the server 
transmits displays to both consoles. It also accepts input from both 
consoles. The server doesn’t assign priority to one console or another. 
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(When you configure a console to permit concurrent sessions from 
different consoles, it’s a good idea to establish your own conventions 
about who’s going to do this, and when.) 


Assuming it’s OK to proceed with a server that’s already running, if 
you are about to start a new session, you probably want to start by 
returning to the monitor or analyzer’s main menu (by pressing F5). 


If you want to use the analyzer and you find that the the server is 
already running it, you can proceed with your work. 


If you want to use the analyzer but you find that the server is at 
present running the monitor, you will have to stop the monitor 
software before you can start the analyzer. 


KON To start an analyzer when the server is running the monitor 


1. Press F5 to return to the monitor’s main menu, and there select 
Exit. 


Result: That returns you to the server’s Selection Menu. 


2. From the selection menu, select Monitor. 


3. Inthe Monitor’s initial menu, select Shutdown the 
Background Processes. 


You'll see a warning message from the server, concluding with 
Do you wish to shut down the monitor? Cy/n] 
Assent by typing y. 


When the monitor has shut down, you'll be back at the 
Selection Menu, but without the Monitor’s background process 
running. Now you can start the analyzer. 


4. Move the highlight to the analyzer you want and press Enter. 
(As you move the highlight to each analyzer, the list of its 
protocol interpreters appears in the menu’s lower panel.) 


Tree-Structure of the Analyzer’s Menus 


The Sniffer analysis server is entirely controlled from menus 

presented on the screen of the SniffMaster console. When you choose 
to run an analyzer, control passes immediately to the analyzer’s main 
menu. An example (for an Ethernet analyzer) is shown in Figure 1-8. 
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1 
Network 
General Cable Tester ¢#| Destination class 
Ea Traffic Generator #4] Station address 
Protocol 
Ethernet Sniffer rigger Pattern match 


Analysis Server Capture dq 
Version 3.5 Display #1 / Good frames 
Files Y Bad CRC frames 
(C) Copyright Options / Fragments 
1986 - 1991 Exit «| / Bad alignment 


Set up filters for frames to be captured. 


—==se the arrow keys to move around in the nenuu==== 


10 New 
capture 


Figure 1-8. Main menu of the Sniffer analyzer (in this case, for Ethernet). 


All Sniffer analyzer menus have the same structure. While details 
vary according to the network and protocol interpreter suites 
installed, the organization is the same. The entire menu is a tree, with 
its root (the main menu) to the left and its branches and leaves to the 
right. Only a part of the menu is visible at a time. Using the cursor 
keys, you move a window over the menu. Since the window is fixed 
on the screen, the menu appears to move under the stationary 
window. 


When the menu is active, the screen shows three panels side-by-side. 
You control the center panel. Within that center panel, the center row 
is highlighted. That is your location on the menu. When you first start 
a Sniffer analyzer, the center panel lists the alternatives available from 
the root of the tree. Some alternatives appear above the highlight, 
some below it. Initially, the highlight is on capture. 


When you press the Cursor Up key, the item above Capture becomes 
highlighted. We speak of “moving the highlight up” to the next item. 
The highlight doesn’t really move; instead, the entire center panel 
scrolls downward so that the (stationary) highlight is now on the row 
above. Alternatively, to jump directly up or down toa particular item, 
you may type the first letter of its name. The highlight jumps to the 
next item beginning with that letter. 


The panel to the right shows choices in the submenu that go with the 
item highlighted in the center panel. As soon as you bring a different 
item to the center highlight, the entire right panel changes. The right 
panel always shows the submenu that goes with the item that’s 
highlighted in the center (see Figure 1-9). 
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Toward root menus 
(How we got here) 


thernet Sniffer 


wrsion 3.65. / 


\ Copyright 


%6 - 1991 


Cable Tester 


Traffic Generator 
Capture filters 


Trigger 


Capture 
Display 


Files. 


Exit 


ACTIVE 
menu 


Destination class 
Station address 
Protocol 

Pattern match 
Good frames 

Bad CRC frames 


Fragments 


Bad alignment 


The Analyzer’s Menus and Controls 


Toward leaf menus 


(Where we could go from here) 


LOOP Etype 
IP Etype 
ARP Etype 
TRLR_ Etype 
PUP Etype 
Other Etype 


Highlight remains at screen center, 
while the menu scrolls under it 


Figure 1-9. Scrolling over the tree-structured menu. 


To select one of the options in the right panel, press the Cursor Right 
key. It’s as if you move rightward from the center of the screen. The 
highlight doesn’t really move. Instead, the entire menu moves 
leftward under the highlight panel. The panel that was to the right 
now moves to the center. The panel that was in the center now moves 
to the left. The panel that was at the left vanishes, as though it moved 
out of sight beyond the left edge of the screen. 


The options associated with the item in the center appear in the panel 
to the right. As you move the highlight to the right, submenus for the 
next level seem to move in from beyond the screen's right edge. When 
the item in the center has no options, the right panel is blank. 


The four cursor keys permit you to traverse the entire menu tree. Your 
current selection always appears at the center of the center panel, with 
other choices at the same level above and below it. The right panel 
shows the submenus (if there are any), and the left panel shows the 
menu nearer the root (or the Network General logo when you're at the 
root). 


Menu Conventions 
The menus contain two kinds of items: 
* Options, and 
* Actions. 


First you set options; then you start an action involving them. 
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Options 


Actions 


An option specifies how an action will work when it starts at some 
future time. Examples of options: 


* Choosing protocols to be included in the filters that decide 
whether to accept a frame. 


* Setting a logarithmic scale for the traffic-density bar graph. 


* Determining whether frames are displayed with the highest- 
level protocol only. 


There are two kinds of options. A checklist is a list of items. Put a ¥ 
beside each that you want, an x beside those you don’t want. You can 
check as many or as few as needed. A radio control is a list of mutually 
exclusive options (so called because, like a push-button radio, 
selecting one deselects the others). A radio control has a vertical bar 
beside it, and an arrowhead at the selected item, thus: 


i Selected item 
Deselected item 


To change an option 
Position the highlight on the option you want, and press Spacebar. 


On a radio control, that moves the arrowhead to the highlighted item. 
Ona checklist, pressing Spacebar changes J to x (or x to /). Holding 
down the Alt key while pressing Spacebar reverses the setting of all 
items on the list. 


An action that can be started by pressing Enter always has # beside it. 


When you press the key for an action, something starts to happen. For 
example, the action Capture causes the Sniffer analyzer to start 
capturing traffic according to the capture options you previously set. 
The action display causes the Sniffer analyzer to start displaying 
frames in the capture buffer according to the display options you 
previously set. 


To start an action 


Position the highlight on the action you want and press Enter. 
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CHAPTER TWO: MONITORING TRAFFIC AND CAPTURING FRAMES ? 


Network 
General 


Chapter 2. Monitoring Traffic and Capturing 
Frames 


Chapter Overview 


This chapter describes the process of capturing frames and the 
displays the analyzer generates as capture proceeds. 


During capture, the Sniffer analyzer “listens” to all frames, filters 
them to select frames to record, and stores the selected frames in its 
capture buffer. As this process continues, the analyzer updates graphs 
or tables that summarize the accepted frames. 


Before you start capture, you need to set a number of options that 
govern the frames that will be accepted and the conditions under 
which capture will halt. The chapter reviews these in the order that 
they appear in the Sniffer analyzer’s menus. 


When capture is complete, you can then analyze, interpret, and 
display the captured frames, as described in Chapter 5, “Displaying 
and Interpreting Frames.” 


Monitoring During Capture vs. Full-Time Monitoring 


While it is capturing, the analyzer counts the arriving frames and 
generates some displays. This activity amounts to some rather 
restricted monitoring. More complete facilities for monitoring are 
provided in the separate Sniffer monitor application. It devotes full 
attention to monitoring and doesn’t attempt to save frames. Thus, to 
get maximum monitoring but no capture, you should run the Sniffer 
Monitor. See the separate manuals Distributed Sniffer System: Ethernet 
Monitor Operations Manual and Distributed Sniffer System: Token Ring 
Monitor Operations Manual. 


The Analyzer’s Process of Capture 


Each accepted frame is stored in the capture buffer. You can store an 
entire frame or truncate it after a certain length. 


If you keep on capturing after the buffer fills, earlier frames are 
discarded to make room for later ones. 


When capture is terminated, you can display and analyze the frames 
in the buffer. That’s when filtering and decoding of higher-level 
protocols takes place. You can also store the contents of the capture 
buffer in a disk file, and subsequently analyze it, or play it back as 
though it were being captured again. 
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Displays During Capture 


Skyline A graph showing traffic density over time; or 


Counters A table of counters, perhaps by logical call and type (ona 
synchronous WAN) or by source or source and destination 
(ona LAN). 


List of Preparations for Capture 


Before you start capture, you specify the frames you want the 
analyzer to retain in its capture buffer and the displays you want to 
see while frames are being captured. 


Many options affect the way the analyzer captures frames. Generally 
speaking, you must set these conditions before you start capturing. 
(However, when you've loaded a setup specifying everything you 
want, or you're happy with the defaults, you can start capture 
immediately, without going through these preliminaries.) 


Figure 2-1 is a list the topics involved in preparation for capture. Each 
of these is described in more detail in the sections that follow. 
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List of Preparations for Capture 


Preparations for Capture 


Check options Several general options affect the analyzer’s operation. They’re set in 
a menu entitled “Options.” 


Set capture filters Filters tell the analyzer which frames to retain and which to discard. 
A capture filter can be based on the presence or absence of the 
following: 

* Unknown address (LAN) 

* Destination class (LAN) 

* Low-level protocol (WAN) 

* Direction (DTE/DCE) (WAN) 

* Pattern (both LAN and WAN) 

* Defects (both WAN and LAN.) 


Set the trigger When it sees a frame containing the pattern, the analyzer stops 
capturing. Preparation has two parts: 
* Set the pattern to look for 
* Set the stopping point (how much to capture) after it’s found. 


Edit the name table During capture, the analyzer labels sources and destinations using 
names from the name table. The unknown station filter considers a 
station “unknown” if its address has no name in the table. 


Set the source The source of capture may be either “live” from the network or from 
a file of previously recorded frames. 


Set the frame size The default is to record the entire frame. To save space, you can have 
the analyzer truncate each frame. 


Set display type * Counters 
* “Skyline” histograms. 


Set counter units * Frames seen 
* Kilobytes seen 
¢ Network utilization. 


Set graph scale The traffic density bar graph’s horizontal scale may be: 
* Logarithmic (default) 
* Linear. 


Set skyline interval Update the skyline at the end of each: 
* Second 
* Minute 
* Hour. 


Set “Highspeed” On Ethernet, you can suppress capture displays to reduce the risk of 
losing frames during a highspeed burst. 


Start capture! * Press F10 (labeled New Capture) 
* Highlight Capture and press Enter. 


Figure 2-1. Steps in preparation for capture. 
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Choices, Setups, and Defaults 


For each step, you may indicate what you want, or (by inaction) 
accept what is already established. “Established” may mean either 


* The Sniffer analyzer’s default setup, or 


* The settings you have restored by loading a previously-saved 
setup file. Loading a setup file restores all the settings the way 
they were at the time the setup file was saved. Procedures to 
save and load a setup file are described in Chapter 5, starting at 
page 5-71. 


Setting the General Options for Each Analyzer 


The Options menu is at the bottom of the main menu’s first panel. You 
probably won't need to change these settings often. They reflect 
general characteristics of the network or the analyzer. 


Token Ring Option to Remove Itself Automatically 


What should the analyzer do if it receives no signal when it inserts 
into the token ring? You may select between two choices: remove the 
server from the ring immediately or remain. The default is to remove, 
indicated in the options menu by the setting: 


Y No signal: remove 


Leaving immediately is a matter of prudence. It protects the ring if 
you should inadvertently connect a server that has been configured 
for one speed to a ring that is operating at a different transmission 
speed. Connecting a token ring station at the wrong speed may 
severely disrupt the ring. 


If you’re certain that the server’s speed matches the speed of the 
network, you can remove this protection. Operating without 
automatic withdrawal has two advantages: 


* When the ring has been broken, you can connect to a fragment 
and await signals as you make other changes to the ring. 


* Ona functioning ring, you can disconnect temporarily and 
reconnect without having to reset the Sniffer server. 


By moving the highlight to No signal: remove and pressing Spacebar, 
you reverse the / (active) to X (inactive). 


LAN Option to Interpret or Ignore the RI Bit in a Source Address 


This option affects the way the analyzer treats DLC addresses on 
networks that use six-byte addressing (including token ring and 


es 


Setting the General Options for Each Analyzer 


Ethernet). Some networks reserve one bit in the source address to 
indicate that the frame includes a field called source routing information 
(RI). On networks that recognize the RI bit, an address really consists 
of only 47 bits. The 48th bit is used in the destination address to 
indicate “broadcast” and in the source address to indicate “RI 

cee uae The broadcast bit is the one that is physically transmitted 
first. 


Effects of enabling “Interpret RI” 


* The analyzer treats addresses as 47 bits 


* The analyzer calls the RI interpreter to interpret the RI field of 
frames that contain this bit in the source address. 


A few networks treat all 48 bits as part of the address. On sucha 
network, the 48th bit is simply part of the address, and does not mean 
that there is an RI field. When analyzing frames from such a network, 
it’s important to disable the option to Interpret RI. (As shipped, the 
analyzer’s default has Interpret RI enabled.) If you don’t turn off the 
interpretation of the RI bit, the analyzer may try to interpret part of the 
frame’s data field as an RI field. 


Effects of disabling “Interpret RI” 


* The analyzer treats addresses as 48 bits 


* The analyzer does not call the RI interpreter and assumes that 
there is never an RI field. 


* The Sniffer analyzer’s “destination class” filter continues to 
recognize the “broadcast” bit in a destination address. Thus the 
filter treats a station whose address includes a 1 in that position 
as if it were a broadcast. 


KOS To treat the high-order bit of the source address as part of the address, 
Sy and not an RI indicator 


1. From the main menu, move to Options. 


2. Move to Interpret RI. Press Spacebar to change J (active, the 
default) to X (inactive). 


RI Fields and “Data Relative” vs. “Frame Relative” 


The IEEE 802.2 standard does not mention RI. IBM introduced source 
routing on token ring networks, and that remains the context in which 
it is most frequently found. In principle, source routing information 


1. Because there are different rules for converting bits-on-the -wire to bits-in-memory, the 
broadcast bit is the high-order bit of a token-ring address, but in an Ethernet address it’s 
the low-order bit of the first byte. 
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can be used not just on token ring but on any LAN that uses six-byte 
station addresses, including Ethernet, StarLAN, or PC Network. 


RI is a variable-length field inserted after the DLC destination and 
source and before the frame’s usual data. When a frame contains an 
RI field, the remaining data field is displaced by the total length of the 
RI field. To allow for the varying size of the RI field, the Sniffer 
analyzer permits you to describe a pattern by either its frame relative 
or its data relative offset; see page 2-25. 


The RI field contains an identifier for each of the routers or gateways 
that forwarded the frame. As it retransmits a frame, each router 
appends its own two-byte identifier! to the RI field. By this means, the 
ultimate recipient has a record of all the intermediate stations that 
forwarded the frame. 


To request that each intermediary insert a record of itself, the 
originating station turns on the RI bit. That instructs each station that 
receives the frame to interpret the first two data bytes as the RI header, 
perhaps followed by a list of gateway identifiers. 


The originating station sets up the RI header. Five bits in the RI header 
record the total length of the RI field (including the header). Initially, 
when no gateway has yet forwarded the frame, the total length of the 
RI field is 2 bytes. Each gateway that forwards the frame appends its 
own two-byte identifier to the list of gateways and increases the RI 
length by 2. 


WAN/Synchronous Options 


WAN Packet type 


You have to tell the Sniffer analyzer what lower-level protocols the 
synchronous link uses. The lowest level may be either SDLC (IBM's 
Synchronous Data Link Control protocol), or HDLC (High-level Data 
Link Control, an ISO standard protocol descended from and closely 
related to SDLC). Neither of these affects what higher level protocols 
are embedded in their frames. The most widely used are SNA over 
SDLC (in IBM installations), and X.25 over HDLC (widespread in 
Europe and increasingly in the US). The analyzer offers two choices: 


HDLC/X.25 ISO X.25 over HDLC (the default). 


SDLC/SNA _ IBM's SNA (Systems Network Architecture) protocol 
over SDLC. 


1, The identifier is composed of a 12-bit ring number and a 4-bit bridge number. These are 


arbitrary numbers assigned by the network administrators. The RI identifier is unrelated 
to the bridge’s station address, 
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WAN Packet Numbering 


WAN Data signalling 


Names in Filters and Displays During Capture 


Packets (frames) may have sequence numbers generated in either of 
two ways that are not readily distinguishable by inspection. One uses 
3 bits, the other 7. Three-bit (that is, modulo 8) numbering is widely 
used within the US and Europe, but seven-bit (modulo 128) encoding 
is often used in Japan and in international satellite links. The menu 
choices are: 


P Modulo 8 (the default). 
Modulo 128 


The two most common encoding methods for SDLC/HDLC are called 
NRZ and NRZI. Before you start capture, in order to decode the 
transmitted data correctly, you should tell the analyzer which one the 
network uses. The choices are: 


| NRZ Non-return to zero (the default.) 
NRZI Non-return to zero inverted. 


Names in Filters and Displays During Capture 


In any of the tabular displays during capture, if the analyzer’s name 
table includes a symbolic name for a DLC address or for the source or 
destination of a logical call, it displays the name rather than the 
address. 


Similarly, any filter that refers to a station’s name also uses the 
symbolic version if the name table provides one. 
To include symbolic names in displays during capture 


1. Before setting filters or capturing, edit the name table to 
include names for the address you expect. See page 5-62 for the 
procedure to edit the name table. 


Alternatively... 


1. Capture for a while without an updated name table. During 
capture, the analyzer will display numeric addresses for 
stations it doesn’t recognize. 


2. Display the captured frames (see page 5-5). When you start 
display, the analyzer scans the capture buffer for addresses and 
lists them in the working copy of the name table. 


3. During the display, if possible, execute Look for names (page 
5-66) or Resolve names (page 5-66). 
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4. Before closing the session or discarding the captured frames, 
execute Edit names (page 5-62). Provide names for all 
addresses. 


5. Before exiting, execute Save names (page 5-61). 


6. Start anew capture session. The analyzer will then display the 
names thus added to the name table. 


Setting the Capture Filters 


From the main menu, move upward until the highlight is on Capture 
filters. At the right you'll see the sub-menu of capture-filter options 
(visible in Figure 2-2). Move the highlight to the right and then up or 
down as necessary to display or edit the options. 


= When you specify a capture filter, you are setting the current capture 
filter, stored in main memory. Doing so does not update any stored 

file containing your Sniffer analyzer’s setup, so the revision is 
temporary. When you have completed your revisions, you can, if you 
wish, save a record of the setup. When you subsequently load the 
setup file, your entire setup will be restored, including whatever 
filters you had set. To save your current setup, move to Files in the 
main menu, then to Save, and finally to Setup. (See page 5-70 ff. For 
more information about saving and loading setup files.) 


Filters for address, unknown, 
x Unknown stns only station, or destination class 


Cable Tester exist only on a LAN. 


4 
Token Timer 4 Destination class 
Traffic Generator # Station address 


Capture filters Protocol ; ; 
ir eee ae Filters for fragments or align 


Capture ment exist only on Ethernet. 


Display Y Good frames 

Files Bad CRC frames Filters for Bad CRC exist 
Options / Fragments only on Ethernet or 

Exit / Bad alignment WAN/Synchronous. 


Figure 2-2. Choices in the “Capture Filters” menu. Some items may be 
omitted depending on the network. 


Five Kinds of Capture Filters 


Figure 2-3 lists and describes the kinds of capture filters. A frame is 
accepted if it is not rejected by any of the applicable filters. (Put 
another way, a frame is accepted only if it passes all filters.) 
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Setting the Capture Filters 


Unknown Should the analyzer accept a frame only No (i.e. no 
station when it contains a source or destination that | restriction) 
has not been assigned a symbolic equivalent 
in the current name table? 


LAN only Destination | Does the frame havea specific destination or | Accept both | 


Network 


class is it broadcast? 


Station Does the frame match any of a list of None set 
address source-and-destination pairs? (accept any) 


Protocol Does the frame contain any of a list of None set 
low-level protocols? (accept any) 


Frame Should the analyzer accept a frame that is Accept 
defects defective, for example, having 


Pattern 
match 


Direction Should the analyzer accept a frame coming | Accept both 
* From DIE 
WAN only * From DCE 


Flow Should the analyzer accept Accept both 
control 


* Alignment error, or 
* Bad CRC. 


Does the frame match a set of patterns you None set 
have specified? (accept any) 


Both LAN 
and WAN 


* RR frames (receiver ready) 


* RNR frames (receiver not ready) 


Figure 2-3. Types of capture filters. 


Time Required for Capture Filters 


Capture filters take a certain amount of processing time. In general, 
the more complex the capture filter, the greater the time. Ona 
network whose load is light or moderate, the processing time is not 
noticeable. But on a heavily loaded network, it limits the speed at 
which the analyzer can accept frames, unless the filter significantly 
reduces the number of frames accepted. If frames arrive faster than 
the analyzer can process them, some may be lost. The number lost is 
recorded in the lost frames counter. If this number begins to rise, it may 
help to adopt a simpler filter. 
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Unknown Address Filter (LAN) 


e 


ON 


Y 


The unknown address filter selects frames whose source or destination 
is unknown to the analyzer. The cause of such traffic could be illegal 
hackers, bad data frames, faulty software in the application or the 
network, or network interface cards that have been replaced without 
notifying the system manager. 


When you check Unknown stns only, the analyzer accepts a frame 
when it contains a DLC address (source or destination) that is 
“unknown.” The analyzer considers an address to be “unknown” 
when 


* Its address isn’t in the working name table, or 


¢ Its address is in the table but without a name. 


To restrict capture to frames from unknown stations 


1. Inthe Capture filters menu, highlight Unknown stns only, and 
press Spacebar to toggle between J (active) and X (inactive). 


2. Inthe Display menu, highlight Manage names. Then select 
Edit names. Edit the table so that 


— It includes the addresses of known stations; 
— Each known address has a symbolic name. 


When you first display frames from a new capture, the analyzer scans 
the capture buffer for DLC addresses that are not in the name table, 
and automatically inserts them in the working copy of the table. 
However, it does not update the permanent name table (file 
STARTUP.xxD) unless you execute Save names. Even then, it saves 
only those addresses that have names. Thus, to assure that observed 
addresses are retained, you must both name each address and execute 
Save names. 


Since the name table is mostly concerned with display, it is described 
in Chapter 5. For instructions on editing the names in the name table, 
see page 5-62. 


Destination Class Filter (LAN) 


Ona LAN, a frame may either be directed to a specific destination, or 
to a generic address that several—perhaps all—stations accept. There 
is no equivalent type of transmission over a wide area network, and 
hence no destination class filter fora WAN/synchronous link. 


In the name table, you can assign a name to a generic address, for 
example “Error Monitor” or “LAN Manager.” Of course, a generic 
address will turn up only as a destination, never as the source of a 


Station Address Filters 


frame. In each network, the prescribed form of a generic address is 
such that it is always different from any possible individual address. 


Networks permit different types of generic addresses and identify 
them differently. The possibilities are summarized in Figure 2-4. 


Originating 
Network 


Multicast 
address 
(including 
Broadcast) 


Ethernet, 
StarLAN, 
PC Network 


Functional 
address 

(including 
Broadcast) 


Token ring 


A multicast address is a 
collective name for several 
stations. It may be a role played 
by one or more stations, or by all 
stations (for example, 
“Broadcast”). 


A functional address is a 
collective name for a role played 
by one or more stations, by no 
station (for example “Error 
monitor” when no station is 
monitoring errors), or by all 
stations (for example, 
“Broadcast” ). 


Description Characteristic Address 


A DLC multicast address has 
a 1 inthe low-order bit of the 
first byte, so that in 
hexadecimal its second 
character is odd (that is, 1, 3, 
5, 7,9, B, D or F). No 
individual station has an 
address with that bit on. 


A DLC functional address 
has a 1 in the high-order bit, 
so that in hexadecimal it 
appears as a number whose 
first digit is 8 or more. No 
individual station has an 
address with that bit on. 


WAN/ None 
Synchronous 


Figure 2-4. Types of generic addresses, by network of origin. 


To select or exclude frames by destination class 


Note the meaning of broadcast address in the network you are 


monitoring. 


Move the highlight to Capture filters and then to Destination 
class. Press Spacebar to select or deselect 


Y Broadcast 
/ Specific. 


Station Address Filters 


During capture, the Sniffer analyzer’s address filters consider only the 
lower levels of addressing. On a WAN/synchronous link, there are 
only two low-level addresses: the two ends of the link. In that context, 
filtering by DLC address doesn’t make sense, and there is no 
provision for address filters during capture from a WAN. 


Ona LAN, you can set filters for a frame’s DLC destination. However, 
recall that the DLC destination may describe only the current leg of a 


2-13 


Distributed Sniffer System: Analyzer Operations Manual 


much longer journey. Higher-level protocols embedded in the frame’s 
data field will have their own addresses; they may cause the recipient 
of the current frame to repack the data and retransmit it with a new 
address. 


During capture from any of the LANs, you may specify up to four 
source-and-destination pairs for the capture filter. You may also 
specify what you want done with others—that is, frames that don’t 
match the specifications you provide. 


Naming the “Matches” Used in Setting Up a Filter 


Each source-and-destination pair that you describe is called a match. 
To make the various matches easier to describe, you may assign them 
names. (The names don’t do anything except help you remember 
what the various matches are for.) Initially, the matches are called 
match 1 through match 4. To assign a name to one of them, move the 
highlight to Match 1 (or whatever) and press Enter. The Sniffer 
analyzer opens a dialog box in which you can write a name (Figure 
2-5). Thereafter, you'll see the name you enter in place of the name 
Match 1. 


x Unknown stns only 


Destination class 
Station address 4 From <any station>€ 


Protocol ENTER MATCH NAME: To <any station>d 
Pattern match 
Reverse direction 


Include these 
| || Exclude these 


Figure 2-5. Naming a match. 
For each match, you specify: 
* Source (select a station name from the name table); 
* Destination(select a station name from the name table); 


* Whether to include frames traveling between the same pair but 
in the reverse direction; 


* Whether the filter should include or exclude the frames thus 
identified. 


KZ To set station address filters for capture 
wy 
1. Move the highlight to Capture filters, then to Station address, 
then rightward to Match 1. 


aie 


Station Address Filters 


2. Optional: To provide a name for this match, press Enter. A 
dialog opens to receive the name. Supply a name, and press 
Enter. 


3. To specify a source address, move the highlight to From and 
press Enter. The analyzer opens a dialog box headed SELECT 
STATION. It contains the list of DLC addresses and their 
current names (Figure 2-6). Move the highlight vertically until 
it shows the station you want, and press Enter. 


Result: at the position labeled From, the server inserts the 
address, using its name if it has one, or the numeric address 
otherwise. 


SELECT STATIONN=————= 


<New station> Length of the 


<Any station> DLC XXXXXXXXXXXX hex station 
Broadcast FFFFFFFFFFFF address 
Fido DLC AAG66301131B depends on the 


Konig DL 626080236318 network 
Gateway P DLC 626080263841 
Score DLC 62628C06388F 


se 4 and Tt then press ENTER, or ESC to return. 


Figure 2-6. Menu to select a station for a station address filter. 


4. Ifthe address you want isn’t in the table, move the highlight to 
<New station> and press Enter. The analyzer opens a dialog 
box to receive your description of the new station. Enter anew 
DLC address and then a symbolic name for it (Figure 2-7). 
Press Enter when done, and return to Step 3. 


SELECT STATION 


Enter the new DLC address of the station The dialog box 
as a hexadecimal value: requires an 
address of the 
426080187066 appropriate 


length. 


Enter the name of the new station: 


Press ESC to abort: 


Figure 2-7. Dialog box for inserting a new station address and name. 


5. To specify a destination address, move the highlight to To and 
press Enter. Supply an address in the same way as Step 3. 


6. To indicate whether this match also applies to traffic in the 
reverse direction, move the highlight to Reverse direction. 
Press Spacebar to toggle between J (include) and x (exclude). 
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7. To indicate whether frames identified by this match should be 
included or excluded, move the highlight to the radio control 
Include these or Exclude these, and press Spacebar at the one 
you want. 


8. Repeat steps 1 through 8 for up to four matches. 


9. To specify what the analyzer should do with frames not 
covered by your matches, move the highlight to Others and 
then to Include or Exclude, and there press Spacebar. 


Combined Effect of Several Matches in an Address Filter 


The Sniffer analyzer evaluates the matches in sequence from Match 1 
(or whatever you have renamed it) to Match 4. As soon as a match 
succeeds, the server ceases to test that frame for further matches. The 
frame’s fate is determined by the way you set the switch 
include/exclude for the match that succeeded. 


When none of the four matches succeeds, the frame’s fate is 
determined by the way you set the switch include/exclude others. 


Using Fewer than Four Matches 


Sample Address Filters 


It isn’t necessary to set all four matches; indeed, you may not want to 
set any at all. In that case, don’t set the matches you don’t want. The 
analyzer disregards a match that contains only the default settings 
Include with addresses From <any station> and To <any station>. 
When all four matches are Include From <any station> To <any 
station>, the Sniffer analyzer does not use any address filtering 
during capture. 


You can temporarily disable a match that you've defined by putting 
an X in front of its match name. The analyzer checks only the matches 
marked /. As usual, you toggle between / and x by highlighting the 

match’s name and pressing Spacebar. 


Suppose you’re interested in traffic between George or Anita and 
Server-1, and also any traffic going to Gateway-A (but not the 
reverse). You could specify three matches as shown in Figure 2-8. 


Station Address Filters 


Match Address Address Direction | Exclude 


ptee | ea 


Defaults 


Default 


Figure 2-8. Example of a filter-match on three address pairs. 


Taking Advantage of the Order in Which Matches are Checked 


Suppose you're interested in all traffic to and from Server-1 except for 
the voluminous traffic between Server-1 and Gateway-A, which, if 
included, would fill up the capture buffer with frames that don’t at the 
moment concern you. Since the address filters are evaluated in 
sequence, you can readily achieve the desired effect by first 
discarding frames between Server-1 and Gateway-A and then 
accepting frames between Server-1 and any destination. The set of 
matches is summarized in Figure 2-9. 


Name for Source Destination Reverse Include/ 

Match Address Address direction exclude 

others 
ef 


Figure 2-9. Address filter to capture all traffic from a station, but with a 
major exception 


Defaults 


Defaults 


Default 
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Protocol Filter During Capture 


While capturing from a synchronous link, there i > no option to filter 
by protocol, so this section applies only to LANs.! 


Ona LAN, each DLC frame includes a field that indicates what it 
contains. Depending on the network, this low-level classification is 
called a SAP (“service access point” in the terminology of IEEE 802.2), 
or an Ethertype (on Ethernet and StarLAN). This is the lowest level at 
which protocols are identified, and the only level that can be used for 
capture filters. (During display, the analyzer can devote more time to 
processing filters, so display filters can include tests for higher-level 
protocols or addresses.) 


When you move the highlight in the Capture filters menu to Protocol, 
the panel to the right shows you a list of protocols. Beside each name, 
there’s a / (check mark) if the capture filter accepts it and an xX if it 
doesn’t. The filter accepts a frame if it contains any of the protocols 
you have marked with a check. 


The specific protocols in the list that accompanies the capture filters 
menu depend on the network for which your Sniffer analyzer is 
proper and the protocol interpreter suites in the analyzer you are 
using. * Some typical protocol lists are shown in Figure 2-10. 


1. In principle, you could filter for SNA or X.25, but since these would not be intermixed on 


the same link at the same time, the filter would do nothing useful. 


2. When you highlight the word protocol, the lower panel lists the installed protocol 


interpreter suites. 
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Token ring with IBM, 
XNS/MSNET, ISO, X.25 


Ethernet with TCP/IP, 
Sun, DECnet, Banyan, 
AppleTalk, X-Windows 


Ethernet with IBM, 
Novell, XNS/MSNET, 
ISO, X.25 


Y MAC frames / LOOP Etype 4 LOOP Etype 
Y SNAP SAP Y¥ Com Netmap Etype Y 3Com Netmap Etype 
Y BPDU SAP ’ IP Etype ’ IBMRT Etype 
Y NetBIOS (IBM) SAP Y ARP Etype / NetWare Etype 
/ SNA SAP ’ TRLR Etype ’ XNS Etype 
# RPL SAP Y PUP Etype Y 3Com NBP Etype 
Y U-BSAP Y PUP ARP Etype Y PUP ARP Etype 
Y IBMNM SAP Y SNMP Etype Y Other Etype 
’ NetWare SAP Y MOP Etype 4 SNAP SAP 
/ ISO CLNP SAP ’ DRP Etype Y BPDUSAP 
Y XNS SAP ’ LAT Etype Y NetBIOS (IBM) SAP 
Y X.25 SAP Y IP (VINES) Etype ¢ SNASAP 
Y Other SAP Y LOOP (VINES) Etype { RPLSAP 
Y Echo (VINES) Etype Y IBMNM SAP 
Y ARP (Atalk) Etype Y ISO/NetWare SAP 
Y LAP (Atalk) Etype Y NetWare SAP 
/ Other Etype Y X.25SAP 
4 SNAP SAP ‘4 Other SAP 
/ BPDU SAP 
¢ LLC (VINES) SAP 
Y Other SAP 


Figure 2-10. DLC protocols typically available for capture filters 


ON To choose the protocols the analyzer will accept during capture 


1. Inthe Capture filters menu, move to Protocol, and then 
rightward to the panel containing the list of protocols. 


2. Move the highlight vertically to the protocol you want to select. 
Press Spacebar to toggle between / (selected) and X (not 
selected). 


3. To reverse the setting for all protocols, press Alt-Spacebar. 


4. The last entry on the list of protocols is “other”; here indicate 
what should be done with a protocol that isn’t any of those the 
analyzer recognizes. 


For most networks, the analyzer’s default setting is to accept every 
protocol. 


Pattern Matching 


A pattern is a particular sequence of bits within a frame. In a simple 
pattern, the bits occur at just one location. In a complex pattern, a set 
of up to eight simple patterns is linked by AND or OR; the effect of 
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NOT is achieved by a setting labeled Match/Don’t match. The 
resulting set of patterns becomes one of the filters applied during 
capture. 


Four Contexts for Pattern Matching 


There are four different contexts in which the Sniffer analyzer lets you 
specify a pattern to look for. As you will see, the pattern can be quite 
complex, involving logical combinations of up to eight component 
patterns. The four contexts are independent; a pattern established for 
one of them has no effect on patterns established for any of the other 
three.. However, the analyzer uses exactly the same mechanism for 
specifying a pattern in any of the four contexts. Therefore the 
discussion that follows, telling you how to set up a pattern for the 
capture filter, applies equally to setting a trigger pattern, setting a 
display pattern, or setting a search pattern. The discussions of pattern 
matching in three other parts of the manual therefore refer you back 
to here. The four contexts for pattern matching are: 


Capture filter During capture, the analyzer accepts frames that 
contain the set of patterns specified in the capture 
filter. 


Trigger Capture can be halted when the server finds that an 
accepted frame matches the set of patterns specified as 
the “trigger” pattern. 


Display filter During display of frames in the capture buffer, you 
can restrict display to frames that match the set of 
patterns in the display filter. 


Search During display, you can have the analyzer search 
forward through the capture buffer for the next frame 
that matches the set of search patterns. 


Setting patterns in the capture filter offers a way of filtering for 
higher-level protocols. Recall that, during capture, the analyzer 
doesn’t have time to invoke its interpreters for high-level protocols, 
and so can’t directly filter on high-level protocols or high-level 
address. However, it does have time to execute fairly complex pattern 
matching. By a little experimentation with captured frames, you can 
often set up a pattern that in effect responds to a high-level embedded 
protocol. 


Establishing a Complex Pattern by Combining Four Matches 


The panel to the right of Pattern match shows the logical rules for 
combining the four sub-patterns into a set. To help recognize the four 
component patterns, you can assign each a name. Your name then 
replaces the default names Match 1, Match 2, etc. Your substitute 
names don’t affect the processing; they only serve to remind you what 
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each component pattern is for. You assign a name to a match in the 
same way that you name a station-address match (Figure 2-5, page 
2-14). That is, move the highlight to Match 1 (or whatever) and press 
Enter. The analyzer opens a dialog box to receive your substitute 
name. 


atch 
Don't match 
x Either offset 


Destination class Y Match 1 < 
Station address Pattern = XXXX... 
Protocol Offset = 200 
Pattern match AND 
OR 
/ Good frames Pattern = XXXX... 
Y Bad CRC frames Offset = 020 
Y Fragments AND 
Y Bad alignment IR Hexadecimal 
4 Match 4 d Character 


Binary 


Figure 2-11. One of the four matches within a pattern. 


Logical Combinations of the Four Matches 


The four matches are combined by logical AND or OR (visible in the 
center panel of Figure 2-11). Initially, these are all set to OR. 


The matches are grouped into two sets of two (Figure 2-11). The 
relation between Match 1 and Match 2 is evaluated first; then, the 
relation between Match 3 and Match 4; finally, the overall relation 
between the outcomes of those pairs. Algebraically (with the symbol 
® standing for whichever relation you set, either AND or OR), it’s 


(Match 1 ® Match 2) © (Match 3 ® Match 4) 


The menu conveys that by its pattern of indents, like a tree with its 
root at the left and its leaves at the right (Figure 2-12). 
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ay 


Figure 2-12. Combining four matches by AND and OR. 


Pair of Patterns within a Match 


Each individual match is in turn composed of a pair of patterns, also 
linked by AND or OR. (Those for Match 2 are visible in the right panel 
of Figure 2-11). When you highlight a match name, the panel to the 
right shows its pair of component patterns (Figure 2-11). Initially, all 
the individual patterns contain X (for anything), and all the offsets are 
00. 


A pattern whose characters are all X has no effect. When you don’t 
need all eight of the individual patterns, you don’t have to set the ones 
you don’t use. Similarly, when you don’t need all four of the matches, 
you don’t have to set the matches you don’t use. When you use some 
matches but not others, it doesn’t matter which ones you use and 
which you leave at their defaults. 


Temporarily Deactivating a Match 


Beside each match, the symbol J indicates that it is active while x 
indicates that it is inactive. Changing J to X lets you deactivate a match 
temporarily without having to erase its specifications. By default, 
they’re all marked “active.” 


Highlighting the match name and pressing Spacebar also serves to 
reactivate a match that you’ve deactivated. 
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A Match on a Pair of Patterns 


Either Offset 


A single match can involve a pair of patterns. (You may prefer to think 
of this as a pattern in two parts). In the menu (Figure 2-11), the two 
patterns appear one above the other, each with its offset. You aren’t 
required to fill in both parts; any part you leave unspecified has no 
effect. 


If you specify two patterns, you must also state the relationship 
between them: AND or OR. The default is AND. That is, to satisfy the 
match, the frame must contain both patterns. 


For each pattern, you specify an offset (its location in the frame). Think 
of them as pattern A at offset a, and pattern B at offset b. Then the 
default match is: 


Pattern A at offseta AND Pattern B at offset b 


Since these two patterns are in the same frame, a frame that meets this 
condition looks like Figure 2-13. 


Figure 2-13. Frame containing both A ata AND Bat b. 


When the relationship is OR rather than AND, either of the frames 
shown in the top part of Figure 2-14 is acceptable. (And of course a 
frame that has both is still acceptable.) 


Figure 2-14. Frames containing either A at offset a OR B at offset b. 


When you specify a pair of patterns, you also have the option to select 
either offset. This usually makes sense only when the two patterns 
are related by AND. 


For example, an exchange between client and server over TCP might 
involve the “well known port” number of the server and a transient 
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port number assigned to the client. In the exchange, the port numbers 
occur at two different positions, corresponding to source port and to 

destination port. Checking either offset with AND causes the analyzer 
to accept traffic passing between this pair of ports in either direction. 


Figure 2-15. Effect of “either offset” when pairs are linked by AND. 


In the unusual (but not impossible) case that you select OR as the 
relation and you also select either offset, any of the four frames 
shown in Figure 2-16 is a match. That filter would accept all traffic to 
or from port A and also all traffic to or from port B. That would 
include traffic between A and B, but it would also accept all their 
traffic with any other ports. 


Figure 2-16. Effect of “Either offset” when pairs are linked by OR. 


Effect of Match/Don’t Match 


For each of the four matches (called Match 1, Match 2, etc., or 
whatever other names you've given them), there is a radio control set 
to either Match or Don’t match. 


This setting reverses the evaluation of each of the patterns within a 
match. “Don’t match” is evaluated before “either offset,” and before the 
analyzer considers how AND or OR combine the pair to form a match. 
To see the effect of “Don’t match,” in Figure 2-13 through Figure 2-16, 
replace “AAAAA” by “Anything other than AAAAA” and replace 
“BBBBB” by “ Anything other than BBBBB.” 


Pattern Matching 


Examples 


Suppose you describe a match as “pattern A at offset a.” Then, setting 
“Don’t match” means that (as far as this match is concerned) a frame 
should be accepted if, at offset a, it has something other than pattern A. 


When a match contains a pair of patterns linked by AND (for 
example, “Pattern A at offset a” and also “Pattern B at offset b”), setting 
“Don’t match” means that (as far as this match is concerned) a frame 
should be accepted if it contains something other than pattern A at 
offset a and something other than pattern B at offset b. 


When you specify a pair of patterns linked by OR (for example, 
“Pattern A at offset a” or “Pattern B at offset b”), setting “Don’t match” 
means that (as far as this match is concerned) a frame should be 
accepted if it contains something other than pattern A at offset a or 
something other than pattern B at offset b.” 


The Overall Outcome 


Whether the frame is in fact accepted depends on the logic you've 
specified for combining the outcomes of the four matches (page 2-16). 


Characters and Offset in an Individual Pattern 


Each individual pattern is described by its position and the characters 
(or bits) it contains. A pattern may contain up to 32 characters. 


Before you specify the pattern’s content, first decide whether you will 
enter it as hexadecimal, as character or as binary. The default is 
hexadecimal. A set of radio controls at the bottom of the panel selects 
one of the three, as follows: 


Hexadecimal Specify up to 16 bytes, each a pair of hex digits 00 
through FF. 


Character Specify up to 32 bytes, each an ASCII character 
enterable from the keyboard. 


Binary Specify up to 4 bytes, as 32 binary bits each 0 or 1. 


In hexadecimal or binary, an X means anything at that position. In 
ASCII character mode, Alt-x has the same effect; when you press 
Alt-x, the corresponding position is shaded, like this: y 


Data-Relative vs. Frame-Relative Offset 


The position at which a set of characters is located is described by its 
offset. On token ring and certain other LANs, some frames contain a 
variable-length field called source routing information. The field, when 
present, comes after the DLC destination and source address, but 
before the regular data field. Thus, the position of data within a 
particular frame depends on whether that frame contains a source 
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> 
Y x. 
KOA, 


routing field. To allow for this uncertainty, you can state the offset in 
either of two ways: 


Frame relative Describe the location as the number of bytes from 
the start of the frame. 


Data relative: Describe the location as the number of bytes from 
the start of the frame’s data segment; that is, from 
the start of the 802.2 frame data. 


When a frame’s source and destination are on the same network, it 
requires no forwarding, and the routing field is frequently (but not 
universally) omitted. When you are confident that all the frames that 
interest you are in the same format (all with a routing field or all 
without), it’s safe to use a frame relative offset. Otherwise, you need a 
data relative offset. When you specify a data relative offset, the 
analyzer adjusts the offset to compensate for the length of each 
frame’s routing field. 


To enter a pattern for the Capture Filter 
(or for the Trigger or Display Filter) 


1. Decide on the logic of your pattern. It can involve up to four 
matches, linked by logical operators AND or OR. (To review 
this part, see page 2-20 ff.) 


Each match can be a pattern-and-offset, or a pair of them. 
When the match contains a pair of patterns, the pair can be 
linked by AND or OR, with or without either offset (page 
2-23). 


Each match can be a vote to include a frame when the data 
match or when the data don’t match (page 2-24). 


If X stands for AND or OR (as appropriate), you can have 


(Match1 X Match2) X (Match3 X Match 4) 


2. Inthe main menu, highlight the option for which you are 
entering a pattern: 
* Capture filter, or 
* Trigger, or 
* Display and then Filters 
and from there highlight Pattern match. 


3. Move the highlight to the match you will define (Match 1, 2, 3, 
or 4). 


4. Ifyou wish to name the match, press Enter. The analyzer opens 
a dialog box to receive your name for the match. 


5. From the match name, move rightward to enter the match’s 
specifications. 
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a. Indicate whether offsets for this pattern are: 
Frame relative 
r Data relative (page 2-25) 
Highlight the desired entry and press Spacebar. 


b. Indicate whether this match votes to include a frame on: 
Match 
Don’t match 
Highlight the desired entry and press Spacebar. 


c. Ifthe match is for a pair of patterns, indicate by / or X 
whether they should be accepted at either offset. 
Press Spacebar to toggle between J and x. 


d. Move the highlight down to the bottom of the panel to 
indicate the type of data for the pattern: 
Hexadecimal 
Character 
Binary 
Highlight the desired entry and press Spacebar. 


6. Move the highlight to Pattern= and press Enter. The Sniffer 
analyzer opens a dialog box in which you can write the 
characters (Figure 2-17). Press Enter to record the pattern. 


ENTER PATTERN 


Enter a pattern in hex, using X for don't-care: 


OBOOXXXXXXXXXXXXXXXXAXXAXAAXAAXA 


(Press t to set the pattern from the data 
currently highlighted in the hex window. ) 


Press ESC to abort 


Figure 2-17. Dialog box to enter a pattern. 


7. Move the highlight to offset= and there press Enter. The Sniffer 
analyzer opens a box in which you can write the value of the 
offset. The offset is always in hexadecimal. Press Enter to 
record the offset. 


ENTER BYTE OFFSET: 


Enter a byte offset in hexadecimal: 


(Press t to set the pattern from the offset 
currently highlighted in the hex window. ) 


Press ESC to abort: 


Figure 2-18. Dialog box to accept a pattern’s offset. 
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Move the highlight leftward to the list of Matches. Select 
another match, and repeat Step 3. through Step 7. as necessary. 


Move the highlight leftward to the list of Matches to set the 
relation between the separate matches. 


a. Set/ or X for each match to enable or disable it. 


b. Set the logical relation between Match 1 and Match 2, 
between Match 3 and Match 4, and between the two pairs 
of matches. For each: 

AND 
OR 
Highlight the desired entry and press Spacebar. 


Cutting and Pasting a Pattern from the Display Hex Window 
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If you have already captured a frame that contains the pattern you 
want, you can have the analyzer copy its characters and its offset, so 
you don’t have to type them. (This procedure makes use of the hex 
and detail views from the display menu, described in Chapter 5.) 


To enter a pattern by copying and pasting 


Set your display to include both the hex view and the detail 
view. 


Find the frame that contains the pattern you want. 


In the detail view, move the highlight to the field you want. 
This automatically moves the hex view’s highlight to that field 
too. 


While the field is highlighted, press F5 to return to the main 
menu. 


Select Capture filters, then Pattern match, then to one of the 
four matches. Move rightward to specify its pattern. 


If need be, move up to select Frame relative or Data relative 
offset. 


Move to the line that contains Pattern= and press Enter. That 
brings you to the entry box shown earlier (Figure 2-17, page 
2-27). 


Press the Cursor Up key. That copies the characters that were 
highlighted in the hex view into the pattern entry dialog box. 
Press Enter to record the pattern. 


Move to the line that contains Offset= and press Enter. That 
opens the other entry box. Press the Cursor Up key. That copies 
the pattern’s offset into the offset dialog box. Press Enter to 
record the offset. 


Pattern Matching 


Example of Pattern Match in a Capture Filter 


The following example is based on the use of Telnet over TCP/IP over 
Ethernet. However, the general strategy for setting a pattern match is 
not specific to the network or protocols of the example. 


Suppose you experience a problem while using a terminal emulation 
package. While connected to a remote host, the network software 
confuses the actions of the Backspace and Delete keys, which (in this 
application) are supposed to do different things. Who is mixing them 
up? The emulator at the PC? The application at the host? The network 
software between them? 


As a first step, you might examine what the emulator transmits to the 
host when you press Backspace and when you press Delete, as well as 
what the host echoes back to each. (Telnet often supports a terminal 
by transmitting one character at a time to the host. Usually, the host 
echoes each displayable character back to the terminal.) 


To study what happens, you need a filter that accepts only those 
frames that include either Backspace or Delete embedded in a Telnet 
frame passing between the host and the terminal emulation program. 
You can’t set a capture filter for the Telnet protocol explicitly (since 
you can’t filter on high-level protocols during capture). But you can 
achieve the same result with pattern matching. Here’s how you 
discover a pattern that identifies not just a Telnet frame, but one 
whose content involves the characters in question. 


First set an address filter to select all frames sent from the terminal 
emulator. Then (from the terminal emulator) do something that 
involves Backspace and then something that involves Delete. 
Browsing through the frames thus captured, you can readily find 
Telnet frames addressed to the host. Examining them, you can see that 
each consists of: 


* ADLC frame (with a DLC source and destination), and within 
that 


* An IP frame (with an IP source and destination), and within 
that 


* A TCP frame (with a TCP source and destination of “Telnet”), 
and within that 


* A Telnet frame containing the record of a keystroke sent from 
the terminal emulator to the host. 


To study how the program treats Backspace and Delete, you take 
advantage of the “cut and paste” facility to set a capture filter to match 
the following pattern. A frame is accepted when: 


* Itcontains the IP protocol number for “TCP” (hex “06” at offset 
17) 
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and 


* It contains the TCP code for Telnet data (indicated by a TCP 
source or destination port number of hexadecimal 17) 


and 


* Its IP source is the address of the PC running the terminal 
emulator, and its IP destination is the address of the host, or 
vice versa (by checking either offset) 


and 


* The Telnet data is either the code for delete (7F) or the code for 
backspace (08). 


IP protocol 
(at offset hex 17) 
= 6, "TCP" 


BOXXXXXXXXXXXXKXXAXXXXAXAXAXAKXX BA 


Pattern Offset 


10.0.0-0-0-0.0.00.0.0,0.0.0.0.0.0.0.0.0.0.0,0.0,0.0,0.0,0.0.0, Gm 1) 


Pattern Offset 
Frame-relative itch x Either 
Data-relative Don't match offset 


TCP source port 

(at hex 22) or 

TCP destination port 
(at hex 24) 


QOL7XXXXXXXXXXXXXXXXXXXXXXXXXXXX 22. 
( ” : Pattern Offset 
BOLTXXXXXXXXXXXXXXXXXXXXXXXXXXXX B24 


= 23 (hex 17), attern Offset 
"Telnet" Frame-relative itch x Either 
Data-relative Don't match = offset 


AND 24 35QBC3XXXXXXXXXXXXXXXXXXXXXAXK O1A 
(ee Pattern Offset 
2438 QOD BX XXXXXXXXXXXXXXXXXXXXAXX Bi1E 
Patten Offset 
6 rame-relative tch Y Either 


IP source address 
Data-relative | Don't match offset. 


= [36.53.0.195] 

(hex 243500C3), 
and IP destination 
address = [36.56.0.208] 
(hex 243800D0), 
or vice versa 


TEXXXXXXXXXXXXXXXXXXAXXXXXXXXXXX 436 
( OR Pattern Offset 
BXXXXXXXXXXXXXXXXXXXXXXXXXXKXXX 436 


Pattern 
Frame-relative 
Data-relative D 


Offset 
tch x Either 
lon't match offset 


Telnet data 

(starts at hex 36) 

is either 7F (delete) 
or 08 (backspace) 


Figure 2-19. Example of a pattern match in the capture filter. 


Figure 2-19 depicts the way pairs of individual patterns are combined 
to form matches, and the resulting matches are combined to form the 
filter. The diagram is shaded to emphasize the way the various 

components are grouped. The fields show data for the example just 
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described. (Of course in a real situation the IP addresses would be 
different, but the values for “Telnet” and “TCP” are appropriate.) 


Filters for Defective Frames 


On a synchronous link or on Ethernet, the Sniffer analyzer can filter 
arriving frames for the presence or absence of certain defects. This 
filter is available only if the network interface card retains defective 
frames and passes them to the Sniffer server’s CPU. The NIC for token 
ring simply discards defective frames. On token ring, these filters 
don’t appear in your capture filters menu and you should skip this 
section of the manual. 


The possible filters are indicated by check marks in Figure 2-20. 


WAN, | Ethernet] 


Good frames Frames having none of the defects 
listed below 

Bad CRC Frames having a defective CRC 
(cyclic redundancy check) 


Fragments v Frames having less than the minimum 
length. (These arise when a station 
detects that its transmission is 
colliding with the transmission of 
another station, and aborts its own 
transmission). 


Bad alignment v Frames whose length is not an integer 
multiple of 8 bits, and hence cannot be 
unambiguously resolved into bytes. 


Figure 2-20. Filters for frame defects. 


ON To set filters for frame defects 


1. Inthe Capture filters menu, move the highlight downward to 
the last section. 


Result: You'll see the list of defect categories for the network 
the analyzer is monitoring. A / mark indicates that frames in 
the category should be accepted, x indicates that they should be 
excluded. 


2. Move the highlight to each category you wish to change. Press 
Spacebar to toggle between J and x. 
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Tabulation of Defects when Categories Overlap 


Defects are described by categories that overlap. A frame with bad 
alignment is probably a fragment and most likely has a bad CRC. To 
avoid counting the same defects several times, the Sniffer analyzer 
does not assign a frame to more than one category of defect. It checks 
for defects in a fixed sequence; when it finds a defect, it records that 
defect but does not count other defects in the same frame. The 
sequence is as follows: 


1. Is the total length sufficient? If not, report that the frame is a 
fragment, and discontinue checking. 


2. Is the alignment correct? If not, report that the frame has bad 
alignment and discontinue checking. 


3. Is the CRC correct? If not, report that the frame has bad CRC. 


4. Ifnone of the above, report that the frame is a good frame. 


Working Definition of “Fragment” 


Ethernet requires that a frame contain at least 60 bytes. Any frame 
with fewer than 60 bytes is considered a fragment, and is so classified 
by the Sniffer analyzer. 


Filters for Direction: From DTE or From DCE (WAN) 


The synchronous link is bidirectional. However, you can elect to 
accept frames in one or the other direction or in both directions. 


We To filter frames by direction during capture from a WAN 
KOA, 


1. From the main menu, move the highlight to Capture filters, 
and then to the panel to the right. 


2. Move the highlight to the direction you wish to include or 
exclude: 
¥ From DTE 
/ From DCE 


Press Spacebar to toggle between J (include) and xX (exclude). 


Filters for Receiver Ready/Not Ready Frames (WAN) 


In the process of setting up communication between the endpoints of 
a synchronous link, and to control the flow of frames once 
communication has been established, the devices (DTE and DCE) 
exchange frames designated RR (“receiver ready”) and RNR. 
(“receiver not ready”). If you're investigating problems in 
handshaking or flow control these may be relevant. When your 
interest is primarily the higher level messages, the RR and RNR 
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Trigger: Specifying When and How to Stop Capture 


frames are usually irrelevant. The Sniffer analyzer provides filters that 
can include or exclude these frames. There are separate, independent 
filters for RR and RNR. 


To filter RR or RNR frames during capture from a WAN 


1. From the main menu, move the highlight to Capture filters, 
and then to the panel to the right. 


2. Move the highlight to the type you wish to include or exclude: 
YRR 
/ RNR 


Press Spacebar to toggle between / (include) and X (exclude). 


Trigger: Specifying When and How to Stop Capture 


The Trigger Event 


It’s important to stop capture at the right moment. You want capture 
to stop while the frames that interest you are stillin the capture buffer. 
When you've elected continuous capture, once the buffer fills, frames 
that arrived earlier are discarded to make room for new arrivals. So if 
you go on capturing too long, the frames you want may have been 
discarded. 


The trigger mechanism gives you a way to stop capture. You can have 
capture halt immediately or somewhat later. Stopping immediately 
leaves you the trigger frame and frames that preceded it. Stopping 
later leaves you a buffer that also contains some frames that follow the 
trigger frame. 


The analyzer stops capture when it detects a trigger event. In the 
distributed Sniffer system, the trigger event is the detection of a 
pattern in an accepted frame. 


When the trigger event occurs, the Sniffer analyzer posts the word 
TRIGGERED at the top left of the display screen. Then, or at a 
specified point thereafter, the server stops capturing frames and 
freezes the capture buffer. The capture buffer contains the trigger 
frame: that is, the frame that matched the trigger pattern. 


At that point, the capture buffer also contains frames that preceded 
the trigger frame, or (optionally) frames that followed it. When you 
set up the trigger, you specify whether capture should cease 
immediately (so that the trigger frame is the last frame in the buffer), 


1. In the stand-alone Sniffer analyzer, the trigger event may also be a signal received at the 
analyzer’s serial port. 
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or ceases when the trigger frame has progressed some percentage of 
the way through the capture buffer. 


Setting the Trigger Pattern and its Position in the Buffer 
There are two parts to setting the trigger: 
* The pattern. 


* The percentage of frames preceding the trigger event. 


LON To set the trigger pattern 
® 


1. In the Sniffer analyzer’s main menu, move the highlight to 
Trigger, and then to Pattern. 


2. Set the pattern following the procedure already described for a 
pattern in the capture filter (see “Establishing a Complex 
Pattern by Combining Four Matches” on page 2-20 ff). 


p KAN To set the position of the trigger frame in the capture buffer 


1. Inthe Trigger menu, move the highlight up to the top item, 
Stopping capture. 


2. Set the radio control to the appropriate percentage. To select 
one, highlight the desired option and press Spacebar. The 
choices are: 

Stop when full 
Continuous capture (the default) 
0% pretrigger 
25% pretrigger 
50% pretrigger 
75% pretrigger 
100% pretrigger 


(The value you pick determines the proportion of space in the 
capture buffer, not the number of frames.) 


The effects of the various stopping options are summarized in Figure 
2-21. 
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Trigger: Specifying When and How to Stop Capture 


Stop when full Even if the trigger event has not occurred, capture stops 
when there is no more space in the capture buffer. 


Continuous capture The frames that arrived earlier are discarded to make room 
in the capture buffer for the newer arrivals. When the 
trigger event occurs, the analyzer (as usual) posts the 
word “Triggered” on the screen, but doesn’t stop 
capturing. If nothing else happens to stop capture, sooner 
or later —depending on the size of the frames and the 
space in the buffer— arriving frames will displace those 
already captured and the trigger frame will be among 
those discarded. 


0% pretrigger Capture continues until the trigger frame is the oldest 
remaining in the capture buffer (frame 1), and all other 
frames follow it. 


25% pretrigger Capture continues until 25% of the space in the capture 
buffer is devoted to frames that arrived before the trigger 
frame. 


50% pretrigger As above, but 50% of the space in the capture buffer is 
devoted to frames that arrived before the trigger frame. 


75% pretrigger As above, but 75% of the space in the capture buffer is 
devoted to frames that arrived before the trigger frame. 


100% pretrigger Capture stops at once, so that the trigger frame is the last to 
arrive in the capture buffer and all other frames preceded 
it. 


Figure 2-21. Effect of “stop capture” options in the trigger menu. 
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Examples of Trigger Patterns 


Figure 2-22 shows two examples of the use of patterns to stop capture. 


Token ring analyzer with IBM Ethernet analyzer with XNS 
interpreter suite interpreter suite 
(monitoring a 3Com+ network) 


To trigger on a frame reporting To trigger on a frame reporting 
an SMB error, you might first set an SMB error, you might first set 
the capture filter to pass only the capture filter to pass only 
NetBIOS frames. Then set the XNS frames. Then set the trigger 
trigger to freeze the capture to freeze the capture buffer when 
buffer when it finds that the it finds that the primary SMB 
primary SMB return code is not return code is not equal to 00 
equal to 00 (zero means (zero means “normal”). In an 
“normal” ).In an IBM SMB frame, XNS SMB frame, the primary 
the primary return code is a return code is a single byte 
single byte located at located at data relative offset 3D 
data-relative offset 27 (hex). (hex). 


Figure 2-22. Sample trigger pattern on token ring and Ethernet. 


Marking the Trigger Frame 


When the Sniffer analyzer matches the trigger pattern, it reports that 
fact by changing the label in the upper left corner of the screen from 
CAPTURING (Figure 2-31, page 2-45) to TRIGGERED (Figure 2-32). 
When you display the contents of the capture buffer, the trigger frame 
is marked with the letter T (see the section entitled Flags Option, page 
5-20). During display, you can jump to the trigger frame, or if you 
wish, display time relative to the arrival of the trigger frame (see the 
section entitled Searching and Jumping, page 5--39). 


The capture buffer never contains more than one frame marked T. 
Suppose you set Stopping capture so that capture continues after a 
trigger frame arrives. Suppose another matching frame arrives. What 
happens? Only the first is considered the trigger frame, and only the 
first is reported and marked. 


The Capture Menu 


After you've set up your capture filters and you've specified when 
capture should stop (in the trigger menu), there are still some options 
you may want to set in the capture menu before you press the button 
to start capture. 


si 


Buffer size 


Frame size 


The Capture Menu 


This item isn’t really an option. It reports the number of kilobytes your 
machine has allocated to the capture buffer. 


To display the size of the capture buffer 
1. Inthe Capture menu, move the highlight upward to Buffer=. 


Result: The size of the buffer in kilobytes is visible as part of the 
item. If the buffer makes use of expanded memory, the number 
if kilobytes is followed by the letters EXP. 


To display a summary of memory allocation 
1. With Buffer= highlighted (as above), press Enter. 


Result: The analyzer displays a summary of memory 
utilization statistics, including DOS data space, expanded 
memory, and various components of the system heap (see 
Figure 2-23). 


Server “Chris F Enet"; F11 for list, Fi2 for menus 
Y STIC 


IEMORY STAT 


DOS data space: 157056 bytes 


Expanded memory: 381288 bytes, 3735552 contiguous 
Capture buffer: 3735552 bytes (Expanded memory) 


DOS ram heap: 
High ram heap: 
Reclaimed heap: 
Normal part: 


5 regions, 
1 regions, 
3 regions, 
7 regions, 


154976 bytes 
65512 bytes 
13384 bytes 

166294 bytes 


Used heap: 100% pieces, 44736 bytes 
Free heap: 9 pieces, 189956 bytes 
Normal part: 7 pieces, min 268, max 65532 
Restricted part: 2 pieces, min 1998, max 20780 
Last request: 264% bytes 


Stack: 23% in use now, 29% max 


Press any ke 


Figure 2-23. Memory statistics display. 


When you're primarily interested in the frames’ low-level headers, 
you can truncate frames that exceed a certain length and thereby fit 
more frames into the capture buffer. On a very busy network, 
truncation may also help avoid losing frames, since a longer frame 
takes slightly more time to store. 
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KV 
he x. 


To limit capture to the first n bytes of a frame 


In the Capture menu, move the highlight to Frame size, and 
then rightward to the panel of frame sizes. 


2. Move the highlight up or down to the maximum length you 
want. Press Spacebar to move the radio control’s selection 
arrow to the highlighted line. The choices are: 


32 bytes 
64 bytes 
128 bytes 
256 bytes 
512 bytes 
Whole frame (the default) 


Effect of Truncating Frames 


When each high-level frame is entirely contained within a lower-level 
frame, truncation leaves you the headers and discards part of the 
high-level data. Since the headers usually contain the information you 
need for analysis, little is lost by discarding the later parts of the 
frame. 


Each high-level frame entirely enclosed in a lower-level frame 


1 ] i ] 


High-level frames, each spanning several lower-level frames 


Figure 2-24. Effect of high-level frames spanning multiple DLC frames. 


However, some high-level protocols (for example, TCP) are 
byte-oriented rather than packet-oriented, and some protocols (for 
example, ISO or X Windows) permit very long messages. As a result 
a single ISO or X message may span several lower-level frames. 


Figure 2-24 shows how a sequence of variable-length higher-level 
frames may be arbitrarily sliced and packed into frames of an 
intermediate byte-oriented protocol such as TCP. The start of a new 
spanned frame is not required to force a new lower-level frame. Thus, 
an X header (for example) may occur at any position ina TCP frame’s 
data field. If your analysis requires keeping track of the headers of 
high-level spanned frames, it is essential to save whole frames, since 
the headers and boundaries of the highest levels may otherwise be 
lost. 
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Formatting the Screen Displayed During Capture 


There are three displays that the analyzer generates as capture 
proceeds (and a fourth option to have no display). They’re listed in 
Figure 2-25. 


These three algo include Ps * Tabulation by source. These two also have 


a thermometer-style totals for “frames seen” 
real-time horizontal ¢ Tabulation by source ax and for frame defects 
bar-graph of momentary and destination. 

traffic density. 


* “Skyline” histogram of 


traffic, by second, 
minute, or hour. 


* None of the above: 
the highspeed option 
suspends display 
during capture. 


Figure 2-25. Options for display during capture. 


Options in the Capture menu select the form of display and the units. 
The options are: 


Units for tables or skylines 
Show Kbyte counts 
Show NW usage 


stow frame counts 


Units for the “thermometer” Linear bar scale 
Log bar scale 


Type of display 
Pair counts 
Skylines 


person counts 


Examples of these displays are shown in detail later in this chapter; 
Figure 2-26 summarizes the places at which the choice of units and 
scale have their effect. The choices are described individually in the 
paragraphs that follow. 


KO To select format of display during capture 


1. Inthe Capture menu, move the highlight vertically to the 
desired options. At each radio control, press Spacebar to 
activate the one you want. 


a 


Distributed Sniffer System: Analyzer Operations Manual 


Frames or kilobytes 
(“usage” shown as KB) 


Individual Counts 


Bar label in: Number of 
Frames/sec, stations 
KBytes/sec, or 

% Usage 


Figure 2-26. Effect of option on display during capture. 


Units in Skylines, Tables, and the Traffic Density Bar Graph 


You can select the units that the analyzer reports during capture. The 
choices and their effects are listed in Figure 2-27. The default is to 
count frames. 


Units Units Totals 
in Skylines (on the traffic (above the traffic 
(when used) | density bar graph) | density bar graph) 


Frame counts Frames Frames 


Units 
in Counters 
(when used) 


Kilobytes Kilobytes Kilobytes Kilobytes unaffected 
(shows both frames 
and Kbytes) 


Network usage Kilobytes Kilobytes Percentage of 
(LAN only) bandwidth 


Figure 2-27. Capture menu options for frames, kilobytes or usage. 


Linear vs. Logarithmic Scale for the Traffic Density Bar Graph 


You can select either a logarithmic or a linear horizontal scale for the 
traffic density bar graph. When the overall density is low, small 
variations are easier to see on a logarithmic scale (the default). These 
are your choices: 


Linear A fixed distance (say 1 cm.) corresponds to an absolute 
change in traffic density (say, 10,000 frames). 


Logarithmic A fixed distance (say 1 cm.) corresponds to a relative 
change (say, 10%), 
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Types of Display During Capture 


This option selects the type of display during capture from among the 
following: 


Individual counts 

Pair counts 

Frame and call counts 

Skylines 

Highspeed (suppresses other displays). 


The default is to display frame-type and call counts (on a synchronous 
link) or pair counts (on a LAN). Characteristics of the alternative 
displays are listed in Figure 2-28. 
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Individual LAN | Traffic is tabulated by DLC source 
counts only address. 
(source) 
Pair counts Traffic is tabulated by DLC source 
only 


(source and and destination address 
Frame-type WAN 

and cal only 

count 


destination) 
Skylines All 
LAN 
WAN 
Ethernet 
only 


Figure 2-28. Characteristics of alternative displays during capture. 


Traffic is tabulated by type, 
separately for DTE and DCE, and by 
logical call. The scrollable panel of 
logical calls may show all calls (the 
default) or only active calls. 


Histograms summarizing network 
activity at selectable intervals. The 
intervals are: every second (the 

default), every minute, or every hour. 


Two histograms: 
* Frames or kilobytes 
* Number of Stations 
Two histograms: 
« From DTE 
* From DCE 


All regular display is replaced by a 
single counter showing only the total 
of frames seen. Frames are stored in 

the interface card’s temporary buffer, 
with about 400K capacity, instead of 
in normal capture buffer. 


Items Always Displayed During Capture 


Totals 


The analyzer always reports the total number of frames it has seen 
(whether or not they passed its capture filters), and the total number 
of kilobytes they contained. On a synchronous link or token ring, 
these totals are reported directly as “frames seen” and “kilobytes 
seen.” On other networks, there is no single total for “frames seen,” 
but separate counts for various subtotals. For example, on Ethernet, 
there are totals for: 
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* Total number of good frames 
* Total number of defective frames. 


* Total number of lost frames. 


Buffer utilization 


As capture proceeds, the analyzer continuously updates a counter 
showing the percentage of the capture buffer that has been filled. 


Momentary and “Highwater” Display of Traffic Density 


As capture proceeds (whether with counters or “skylines”) the Sniffer 
analyzer displays a thermometer-style horizontal bar to show 
real-time variations in traffic density (Figure 2-29). For LAN traffic, 
there’s a single bar. On a synchronous link, there are two separate 
bars, one showing traffic from DTE and the other showing traffic from 
DCE. Each bar is updated several times a second. Each shows a 
moving average of the last half second’s activity and the “high 
water”—that is, the maximum recorded during the current capture 
session. 


Local area network, with frames option 


Frames per second 


Figure 2-29. Traffic density bar graph for LAN and for WAN. 


Line Status on the Synchronous Link 


Whether you choose counters or skylines, during capture the 
WAN/synchronous analyzer includes a one-line summary of the 
line’s status (Figure 2-30). The display shows the RS232 indicators 
RxC, TxC, RxD, TxD, CTS, RTS, DSR and DTR. The condition of each 
is indicated by the symbol T J or f. 


Interpreting the Arrows 


The symbol f indicates a logical 1, | indicates a logical 0, and 1 
indicates that the indicator’s status has changed in the last second. But 
what does a logical 1 mean? That depends on the way the server is 
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connected to the synchronous line. When the connection uses the 
DB-25 (RS232) connector supplied with the server, 1 (the up arrow) 
indicates active, enabled, or OK. But when the connection uses the 
optional V.35 interface pod, the significance of the signals for CTS, 
RTS, DSR and DTR is reversed: for those indicators, 0 (the down 
arrow) indicates active, enabled or OK. See the section entitled 
“Connecting a WAN Server” in Chapter 3 of Distributed Sniffer System: 
Installation and Operations Manual. 


®@ CRC Errors tRxC tTxC tRxD tTxD TCTS tRTS TDSR tDTR 8 Lost Frames 


Figure 2-30. Line status indicators on a synchronous link. 


What the Capture Screens Look Like 


The examples that follow illustrate the various types of display 
during capture —counters and histograms— on both local and wide 
area networks. 


Capture with Pair Counts on a LAN 
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The analyzer allocates a slot for each pair of communicating stations, 
and updates them as frames are accepted. The counters show either 
frames or kilobytes, as you elected in the Capture menu. 


The table is initially blank. As the server notices traffic between a 
station pair that it hasn’t seen before, it adds an entry. For each pair, 
there’s a counter for traffic in the direction first observed, anda 
second for traffic in the reverse direction. The number closest to the 
station’s name describes transmissions from that station to the other 
station. 


The analyzer adds pairs as it encounters them until it has used all 
available positions on the screen. After that, it continues to update the 
grand totals and the counts for the entries on the screen, but does not 
record details of pairs that aren’t on the screen. (To clear the screen 
and start the tabulation anew, press F4. This doesn’t affect the frames 
in the capture buffer.) 


Figure 2-31 shows the screen following a lengthy capture with pair 
counts. Although it was recorded from an Ethernet LAN, the screen 
would be quite similar for token ring. Figure 2-33 (page 2-47) shows 
a screen reporting capture on a synchronous link. 


In Figure 2-31, most stations are identified by names because a name 
table containing most of the DLC addresses had been created before 
capture started. The table had no name for the station shown as 
Exceln923931. The address that appears as AAAAAAAAAAAA (in both source 
and destination!) is spurious; in this particular case, it appeared 


What the Capture Screens Look Like 


because a station with a defective card transmitted several fragments 
when first turned on. Each fragment contained nothing but the 
character hex A in every field. Setting the capture filter to exclude 
defective frames would eliminate this spurious entry. 


CAPTURING Number of frames from the station 63:47:33 
SERVER BIZ-1|SERVER BIZ-1 EXE) Bruce 
Broadcast |SERVER BIZ-1 eye) Carol 
bWsee| Kent 
SERVER BIZ-1 Exce1n923931 Broadcast 
SERVER BIZ-1 Exce1n923931 YALE SERVER BIZ-1 
SERVER BIZ-1 Cathy Broadcast 
SERVER BIZ-1 AAAAAAAAAAAA 
SERVER BIZ-1 Broadcast 
SERVER BIZ-1 Broadcast 
SERVER BIZ-1 y Broadcast 
SERVER BIZ-1 Quien Sabe 9 Broadcast 
j Matthew 2 Broadcast 
SERVER BIZ-41 SUPERVISOR 4 Broadcast 
SERVER BIZ-1 / Kristen Broadcast 
SERVER BIZ-1 
SERVER BIZ-1 
>44867 Good 
>44896 Fra 


Frames per second 
4 Clear} 9 18 Stop 
scree Pauselcapture} 


Figure 2-31. Capture screen showing pair counts. 


Capture With Individual Counts on a LAN 


Individual counts (Figure 2-32) work in much the same way as pair 
counts. The analyzer adds an entry to the screen for each station that 
transmits, in the order encountered. Because these entries record the 
sender but not the destination, fewer total entries are required, and 
each takes less space. So the screen has room for a greater number of 
entries. As with pair counts, the server adds entries until all positions 
on the screen are filled. Then it continues to update the grand totals 
and the counts for the entries on screen, but does not record details of 
stations that aren’t on screen. (To clear the screen and start tabulation 
anew, press F4; that doesn’t affect frames in the capture buffer.) 
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TRIGGERED Number of frames from the station 81:26:24 
Mktg_Q Carol il Manuf 16 
SERVER Sys 1 Kristen C L Poda 1 


Cathy fs] Atlantis Sun Kate 

SUPERVISOR 1 Term Server [RUyAil| NwkGn 1620267 
Kirk PRINT Sni 

Jay RND Server 

Dale TS James #2 

Matthew 2 Len 


Shauna Valerie 
Bruce Doug 
Unknown 9 Dwarfs 
Renita Chris 

Kent Sparta SUN 
Matthew 1 Car 
SUPERVISOR 2 David 
Karen James 


123848 Good 
123041 Frames 


@ Bad CRC 6 Lost 
Buffer utilization 


1260 320 
4 Clear} 9 18 Stop 
scree Pausefimcapture| 


Figure 2-32. LAN capture screen showing individual counts. 


Frames per second 


Capture with Frame Counts on a Synchronous WAN 


Counters 


X.25 or SNA 


Logical calls 


On a WAN/synchronous link, the metering screen during capture is 
divided into three zones (see Figure 2-33). On the left there are 
counters showing either frames or kilobytes for each of twelve HDLC 
types, totaled separately by direction (from DTE and from DCE). 


The center zone has counters showing either frames or kilobytes at the 
next protocol level, either X.25 or SNA (according to your choice in the 
frame type item in the options menu). Since only information frames 
have SNA or X.25 content, the total number of frames in the center 
panel may be lower than the total in the left panel. 


In the third zone, the analyzer builds a table of logical calls, in the 
order encountered in the traffic. Each call is identified by its LCN and 
by its call address (if known). The LCN is composed of a logical 
channel group number and logical channel number. 


A column at the right shows whether each call originated from DTE 
or from DCE. For each call, the analyzer tabulates traffic on that 
connection in each direction. 
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The LCN table is open ended, depending on the number of calls 
identified while capture continues. When the number of calls becomes 
larger than the number of lines allocated in the viewing panel, you can 
scroll the list by pressing the Cursor Up or Cursor Down keys, or F7 
or F8. 


Active vs. completed calls 


Unknown LCN Address 


The logical call table includes both calls that are still active and calls 
that have been completed. The counts for calls that are still active are 
highlighted. (In Figure 2-33, the counts 79 and 60 for LCN 014 are 
highlighted, indicating that the call is active, whereas those on the 
preceding and following rows are no longer active and hence are not 
highlighted.) 


You may restrict the display to completed calls by pressing F2. 
Pressing F2 again restores the display to include all calls. Once a call 
has been completed, its logical call number may be reused, so the 
inactive calls may include multiple instances of the same LCN. 


A logical call’s address is contained in its first frame. If a call began 
before the Sniffer analyzer started to capture, its LCN is known but 
not its address. The address for such a call is shown as a row of 


dashes. 


CAPTURING Frame Counts 00:28:23 
HDLC Level X.25 Level X.25 LCN and Addresses 
DTE DCE LCN Calling/Called From 
1 1 018 DCE 


014 000000020308 ODTE 
118 600000020306 DTE 
al 118 Dona Abigail DCE 
808 91455556882 ODTE 
1 E18 080007844926 DCE 
[f) Q@E8 Lum Express  ODTE 
sy, 8A --------------- DTC 
“| $88 Ti Dezod DTC 
ha!) §B2 YYZ Gateway  DTE 
bl Fif 600007071845 DCE 
Bl 802 920000044008 DCE 
o see more, scroll up or down 
® CRC Errors ?RxC ?TxC ?RxD ?TxD TCTS tRTS TDSR tDTR @ Lost Frames 
1388 frames seen. @ Kbytes, 388 frames accepted. 4% buffer used. 


2 100 = 35 2 108 = 358 

Frames per second 
iy 2Disply 4 Clear i/Scrollg8Scrol1g9 18 New 
Helpam Active scree! up down §§ Pause ficapture| 


Figure 2-33. WAN capture, with counts for HDLC, X.25 and logical call. 
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Names for Addresses 


You can supply names for the source or destination of a logical call. 
The mechanism is the same as names for station addresses on a LAN 
(see page 5-12). The analyzer substitutes the name for the remote 
address (the source on a call from DCE, the destination on a call from 
DTE). Names for addresses are visible in the right panel of Figure 
2-33. 


Capture with Skylines 
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A skyline is a real-time graph of traffic density. It shows a histogram 
that is updated by adding a new column at the right every second, 
minute, or hour, depending on the time scale you selected before you 
started capture. With the skyline (as with the table of counters), you 
also get a count of total frames, but no other itemization. 


CAPTURING AE 93:29 
ti) ee ee Pe a Ne ce A Te SO Se 


agments isaligne 
74689 Frames sccerted 15274 Kbytes accepted ‘0 Buffer utilization 


Tames S Seco} 
2Select 4 Clear} S Scaleli6 oat / View 98 View 10 Stop 
display scree up down flearlierff later eal capture| 
Figure 2-34. Skyline display on a local area network 


A skyline always has two graphs, one above the other, with a common 
horizontal time scale. On a LAN (Figure 2-34), the upper histogram 
shows either the number of frames or the number of kilobytes 
transmitted during the interval, according to your choice of units in 
the capture menu. The lower histogram always shows the number of 
stations active during the interval. 


On a WAN/synchronous link (Figure 2-35), the upper histogram 
shows traffic from DTE, while the lower histogram shows traffic from 
DCE. 


Capture Source: Live or Playback 


CAPTURING 00:03:34 
(ide: 5. Bi Ge Se Se Bo oe A I ee Se Gs Ge Ge fe ee eho 


rrors x xD TCTS TRIS tT TDT. ost Frames 
12147 frames seen 24483 Kbytes, 12147 frames accepted 91% buffer used. 
D DCE 


6 = 35 
Frames per sec 


2 1 2 106 = 350 

ond 
2select| 4 Clear ScalefM6 Scalefi7 View 98 View #9 = —f10 New 
display screen up “Down earlier later J Pause capture 


Figure 2-35. Skyline display on a WAN synchronous link. 


Vertical Scale and Horizontal Time Span of the Skylines 


Capture Source: 


You can have the vertical axes calibrated on either a linear or a 
logarithmic scale, as you request in the capture menu. Whichever you 
choose applies to all the histograms. 


You can also adjust the scale of each vertical axis independently. 
Pressing F5 (labeled scale up) gives you taller bars (on a smaller 
range), while pressing F6 does the reverse. You can press either of 
these while collection proceeds. 


The scale up or scale down keys affect only one of the skylines at a 
time. The one affected is the one for which the label on the vertical axis 
is highlighted. In Figure 2-34 or Figure 2-35, the word “frames” that 
labels the upper skyline appears in bold (or in a contrasting color on 
an external color monitor) to indicate that the upper skyline is active 
and will respond to scale up or scale down, whereas on the lower 
skyline the label #stns is not. 


To move the highlight (and the effect of F5 and F6) from one skyline 
to the other, press F2 or the Tab key. 


Live or Playback 


The source from which frames are captured is controlled by the 
capture option labeled From <xxxxx>. At the bottom of the capture 
menu, you'll see From followed by the name of the network, for 
example From Ethernet or From token ring, etc., as appropriate. 


2-49 


Distributed Sniffer System: Analyzer Operations Manual 


KD 
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Highspeed Capture 
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When you capture from a file, this part of the menu shows From 
followed by the name of the file. 


To capture from a file 


ite 


From the analyzer’s main menu, move the highlight to 
Capture. 


Move the highlight to From <xxx> and press Enter. (From is at 
the bottom of the menu; initially, it may be below the lower 
edge of the panel. Scroll down until you come to it.) 


Result: The Sniffer analyzer opens a dialog box from which you 
can select the source you want. Initially, the dialog box shows 
the names of trace files (that is, files of saved frames) in the 
CAPTURE directory of the Sniffer server’s hard drive. 


Within the dialog box, move the highlight up or down to select 
the file you want, and press Enter. 


Result: The analyzer closes the dialog box, and inserts the name 
of the selected file in the capture source. 


To move to a subdirectory within the current directory: 
highlight its name and press Enter. 


To move to a directory closer to the root: move the highlight 
upward to the first entry (labeled “. .”) and press Enter. 


To capture from the network 


Ls 
2. 


... when the current capture source is a file 
Proceed as described in “To capture from a file.” 


Within the dialog box, move the highlight to the first line. It 
contains the name of the network (for example, <Ethernet>). 
Press Enter. 


Result: The analyzer closes the dialog box, and inserts the name 
of the selected network in the capture source. 


Under certain conditions, sustained highspeed traffic might outrun 
the analyzer’s ability to capture every frame. On Ethernet, to permit 
the server to give maximum time to the process of capture, the 
highspeed option stores frames in the interface card’s temporary 
buffers instead of in the area of main storage dedicated to the capture 
buffer. This speeds up processing considerably. However, it also: 


Limits storage to the approximately 400KB of the NIC’s buffer, 
Bypasses filtering, and 


Capture Source: Live or Playback 


Prevents the analyzer from generating its usual display of 
counters or skylines. 


You still get a count of total frames, displayed in a small panel 
superimposed on the usual display, which is otherwise frozen. 


The Capture menu includes the highspeed option only on Ethernet 
(the only network for which the interface card provides 
programmable access to the local buffer). 


To start capture in highspeed mode on Ethernet 


1; 


In the main menu, highlight Capture and then move rightward 
to its submenu. Move the highlight down to Highspeed (it’s at 
the bottom, initially out of sight below the lower edge). Press 
Enter to toggle X (inactive) to / (active). 


In the Capture menu, select Individual counts or Pair counts, 
as you prefer. (You can select Skylines, but if you do, during 
highspeed capture the effect is the same as selecting Pair 
counts.) 


Press F10 to start capture. 


Result: The analyzer puts up the framework for the counts you 
requested but does not fill in any data. A rectangle in the center 
is superimposed for the highspeed counts. As capture 
proceeds, only the central rectangle is updated. 


When you press F10 (Stop capture) or F9 (Pause), the analyzer 
transfers the frames that have accumulated in the NIC’s buffer 
to the analyzer’s capture buffer. Then it displays the 
accumulated statistics in the format you requested (pair counts 
or individual counts). 


Figure 2-36 illustrates a screen visible during highspeed capture. 
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Figure 2-36. Screen during highspeed capture on Ethernet. 


Starting Capture 


When you have set up the capture filters and triggers and have 
specified the capture options you want, you're ready to start capture. 


0) To start capture 
1. Check that you've set the capture filters and options as you 
want them. 


2. Press F10 (New Capture). 


Or, in the main menu, move the highlight to Capture and press 
Enter. 


Result: The Sniffer analyzer starts capturing frames. The screen 
changes to the type of display you've chosen (frame counts, 
pair counts, individual counts, or skylines) with the scales and 
measures you indicated. 


Ethernet Cable Test 


On Ethernet only, if this is the first capture since the analyzer program 
started, the analyzer runs a cable test before it starts capturing. In the 
event it detects a cable fault, it displays the message “There appears to be 
a cable or transceiver fault,” followed by some diagnostic information. 
You can then stop to investigate or proceed with capture. The cable 
tester is described in Chapter 3. 


a 


Stopping Capture 


Stopping Capture 
Once started, capture continues until one of the following happens: 
* You press F10 to stop capture; 


* The trigger event occurs (if you specified that capture should 
stop then); 


* The buffer fills (if you specified that capture should stop then); 


* You press F9 to pause capture. That permits you to adjust the 
display or capture filters and then resume capturing frames. 


What You Can Do While Capture is Paused 


If you press F9, the analyzer pauses its capturing. Frames are no 
longer being captured, but the frames already captured remain in the 
capture buffer. At that point, you can press function keys as follows: 


F1 Help This is the same help facility available 
throughout the analyzer (but not accessible while 
actively capturing). 


F9 Resume When you press Resume, capture continues. The 
next frame to be captured is appended to the 
capture buffer immediately following the last 
frame captured before you press Pause. There is 
no special mark to show that a pause occured. 
Frames that arrived during the pause are simply 
missing. 


F4 Clear screen This clears the current graph or tabulation on the 
screen, but doesn’t affect frames in the capture 
buffer. 


F6 Capture options This permits you to change the capture options, 
but doesn’t affect frames in the capture buffer. 


If you make any changes to the options, filters, 
etc., when you press Return (F6) or Resume (F9), 
the server will clear the screen before resuming. 


F3 Data display = This stops capture and takes you to display; after 
this, you can’t resume your earlier capture (but 
you can start a new capture, which will first clear 
the capture buffer). 


What You Can Do When Capture Has Stopped 


Once capture has stopped, you can do any of the following with the 
frames in the capture buffer: 
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Display them 


Save them 


Discard them 


Chapter 5 tells you how to display frames once they're 
in the capture buffer. 


The saved frames go to a file on the server's hard disk. 
(You may subsequently move that file to the console, 
using the file transfer utility). 


A file of captured frames can be used as: 

* A source from which you “capture” frames 
(see page 2-49). 

« A source from which you load the capture buffer 
(see page 5-68). 


When you start a new capture or exit from the Sniffer 
analyzer program without having saved the contents 
of the capture buffer, the analyzer warns you that if 
you proceed it will discard the frames now in the 
buffer. 
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CHAPTER THREE: NETWORK-SPECIFIC TESTING 3 


General 


Chapter 3. Network-Specific Testing 


Chapter Overview 


Chapter 3 describes analyzer services that are specific to a particular 
network. Such a service shows up in the analyzer’s main menu only 
when you're using a server for that network. Since most of the 
analyzer’s functions are available across the board to any of the 
supported networks, this is a short chapter. In the current version of 
the distributed Sniffer system, there is only one network-specific 
service: the Ethernet cable tester. 


This chapter describes: 
* What the cable tester does 
* How you invoke it 
* How you interpret its reports of a short or an open circuit. 


The chapter concludes with some notes on limitations of the cable 
tester. 


Ethernet Cable Tester 


On Ethernet, the Sniffer analyzer provides a cable tester: a means to 
check and report cable faults. The analyzer’s main menu includes an 
option labeled Cable tester (Figure 3-1). The cable test uses the 
server's “monitor” interface card as a time-domain reflectometer. 
During the test, the analyzer repeatedly emits a pulse and listens for 


the echo characteristic of certain types of faults. 


To test the Ethernet segment for cable faults 


1. In the analyzer’s main menu, move the highlight to Cable 
Tester and press Enter (Figure 3-1). 


Result: The analyzer repeatedly emits a test signal on the 
Ethernet segment to which the server's “monitor” card is 
attached. The analyzer overlays a display reporting what faults 
—if any— have been detected, and updates it as the test is 


repeated. 


2. To terminate the test, press Esc. 
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Figure 3-1. Cable test in the main menu of the Ethernet analyzer. 


The cable tester keeps testing until you terminate it by pressing Esc. 
While the test is running, the analyzer does not perform any of its 
other functions. 


As long as the tester is active, the Sniffer analyzer repeatedly updates 
the display transmitted to the console so that the display shows the 
cable’s current status. As long as it detects no fault, it displays the 
message No cable fault found. 


The analyzer can detect a cable fault located between the “monitor” 
adapter and the transceiver that connects it to the network. It can also 
detect an open line ora short in the network cabling beyond the 
transceiver (Figure 3-2 and Figure 3-3). The Sniffer analyzer cannot 
test for faults, open lines, or shorts on cable segments separated by a 
bridge or repeater from the segment on which it is located. 


Automatic Test at First Capture 


3-4 


Under some circumstances, when you ask to start capture, the 
analyzer first runs a brief cable test. It does this automatically, without 
being asked. It runs the automatic test only when this is the first live 
capture since the analyzer program started. 


If the automatic test discovers no fault, there is no display and the 
analyzer proceeds directly with capture. 


1, Ifthe analyzer was already se Real when you connected to the server, the analyzer may 
1 


have been running for a considerable time—even days or weeks. 


Ethernet Cable Tester 


If the automatic test detects a cable fault, the analyzer reports it, and 
gives you the choice to proceed with capture or to halt. 


Inferring Distance from Time 


To locate a fault, the Sniffer analyzer notes the interval between its test 
pulse and the echo that the fault generates. It reports this time in 
nanoseconds with a resolution of about +50 nanoseconds. To estimate 
the probable distance, it divides the time by an estimate of the speed 
at which the signal propagates through the cable. The actual speed 
varies not only with the type of cable but also several other factors, 
including the type of transceivers and connectors, as well as 
variations in the network's layout. 


The analyzer computes two estimates of the distance to the fault. It 
bases one estimate on the average propagation speed through 
standard Ethernet cable, which it assumes is about 0.79c. (The 
constant c represents the speed of light in a vacuum, about 0.3 meters 
per nanosecond.) It bases the other on the average propagation speed 
through thin cable (“Cheapernet”), which it assumes to be about 
0.66c. These calculations have no way to allow for variations 
introduced by the actual conditions on the specific network segment 
the server is monitoring. 


Cable open at 15% nanoseconds 


117° (35 M) of Ethernet, 96° (29 M) of Cheapernet 
Press ESC to sto 


Figure 3-2. The Ethernet analyzer’s report of an open cable. 


Since the resolution of the device producing the timings is to the 
nearest multiple of 50 nanoseconds, the estimate of distance would 
have an inherent uncertainty of +10-12 meters, even if the 
propagation speed for the segment involved were known precisely. In 
practice, there is uncertainty about the average propagation speed for 
the network as a whole and uncertainty about the specific part 
generating the signal. Also, it may be difficult to know the actual 
lengths of the cables when they’ re concealed behind furniture, in the 
walls, above the ceiling, and so on. Nevertheless, even an uncertain 
estimate of distance may serve to bracket a range in which the trouble 
probably lies, and to rule out portions of the network at grossly 
different distances. 
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Cable short at 65% nanoseconds 
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Figure 3-3. The Ethernet analysis server's report of a short. 


To help you interpret the Sniffer analyzer’s reports when you really 
need them, it may be useful to run some calibration tests in advance. 
Deliberately introduce faults at various known locations. For 
example, disconnect a cable and leave it without a terminator while 
you run the cable tester. Note the time and distance that the Sniffer 
analyzer reports. Note how the report varies during other normal 
changes (for example, adding or removing a station). It may prove 
useful to save a table of your observations so you can compare them 
to the reports you get when the Sniffer analyzer finds a real fault. 


Limitations of the Cable Tester 


The Sniffer analyzer readily detects an open line and produces 
a steady diagnostic display. The reflection characteristic of a 
short circuit between the center conductor and ground is 
harder to discriminate from a normal signal, so the server 
sometimes misses it. 


Certain intermittent defects can produce a jittering display. As 
it continuously updates the display, the Sniffer analyzer may 
assign different diagnoses to a continuously changing 
situation. 


When a collision anywhere on the network coincides with a test 
pulse, the resulting signal is similar to the pattern produced by 
an open line. However, a collision produces no more than a 
momentary flicker. 


Transceivers vary in the way they transmit the test pulse and 
its echo. This variation in turn produces variation in the 
behavior of the cable tester. Most transceivers produce useful 
results, but some do not. 


The procedure for converting time estimates to distance is 
subject to numerous unpredictable sources of variation. 
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Network 
General 


Chapter 4. Generating Traffic to Load the 


Network 


Chapter Overview 


The Traffic Generator is part of the Sniffer analyzer for Ethernet and 
token ring but not of the analyzer for a WAN/Synchronous link. 


The traffic generator permits you to load the portion of the network 
that the server is monitoring with background traffic. You might do 
this to observe how other stations respond to delays introduced by a 
large volume of unrelated traffic, or to test the response of an 
individual station to heavy traffic of a particular type, or to test the 
action of gateways and bridges. 


Transmissions generated by the traffic generator always obey the 
network’s normal rules for transmitting. For a COMA/CD network 
such as Ethernet, that means using the standard collision-detection 
and back-off algorithms. For a token-passing network, it means 
waiting for a free token and following the appropriate low-level 
transmission protocol. 


The traffic generator sends the same frame repeatedly (except that it 
inserts a counter in the frame’s data field). You can specify: 


* Total length of the frame 

¢ Interval between frames 

¢ Destination address 

* Content of the first thirty-two data bytes. 


By specifying the first 32 bytes appropriately, you can generate frames 
that appear to the recipient to have a particular SAP or Ethertype, or 
frames to which no station should respond. 


Don’t Swamp the Transport Link Between Console and Server! 


If the analysis server's two interface cards are both connected to the 
same network —that is, your console is exchanging control 
information with the server by way of the network that the server is 
monitoring— watch out! Flooding the network with traffic may 
swamp the connection back to the console, making it difficult or even 
impossible to receive timely reports from the server, and —worse 
yet— making it difficult or impossible to give the server new 
instructions. If console and server fail to maintain contact within their 
time-out parameters, you may lose your connection to the server. 
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Preparing to Generate Traffic 


Figure 4-1 shows the main menu panel from which you select the 
traffic generator. Pressing Enter at any of the options with # opensa 
dialog box in which you supply a value or select a destination. Before 
you start generating, you may set the destination, size, delay, number 
of frames to be sent, and the content of the data field. 


Cable tester d 
Traffic Generator # 
Capture filters 


To <all stations> fg 
ize = 1960 ¢d 


Trigger Delay = 19.82 ¢ 
Capture <q Frames = INFINITE # 
Display #| Data = 02000000...< 
Files 

Options 


Exit 4 


Transmit to the designated station(s). 


Press ENTER to change the statio———======= 


19 New 
capture} 


Figure 4-1. The traffic generator menu. 


Destination 
The traffic generator menu starts with the generated frames’ 
destination address. In the center of Figure 4-1 you can see that it says 
To <all stations>, which is the default. The destination must be a 
DLC-level address. 
To set the destination of the generated frames 
1. Inthe Traffic generator menu, move the highlight to To... and 
press Enter 
Result: The analyzer opens a dialog box showing you a list of 
DLC addresses currently in the working name table. 
2. Move the highlight to the address you want, and press Enter. 
Result: The destination field now shows To followed by the 
name or address you selected. 
4-4 


Group destination 


Preparing to Generate Traffic 


For example, if you select an address whose name is James, the 
menu item now says “To James.” If you select an address that 
has no symbolic equivalent (for example, IBM 002FEB), the 
menu item then says “To IBM 002FEB.” 


3. Toadd anew address to the list, move the highlight to <New 
station> and press Enter. 


Result: The analyzer opens a dialog box in which you can write 
a new DLC address and a symbolic name for it. To select the 
new address as the destination, return to step 2 (above). 


You may choose a broadcast address rather than the address of a 
specific station. Depending on the network, there may also be various 
classes of group address. 


Size of the Generated Frame 


The size option sets the total length of the frame to be generated, in 
bytes. The minimum and maximum permissible lengths depend upon 
the network, as shown in Figure 4-2. 


16 Mbps 


12 18 18 
1514 4458 17954 


Figure 4-2. Size of frames the traffic generator can send. 


Min (bytes) 
Max (bytes) 


On Ethernet, the length of the smallest valid frame is 60 bytes. Shorter 
frames normally occur only as collision fragments. The Sniffer 
analyzer is capable of generating short frames. When you specify a 
length less than 60 bytes, you get a warning that other stations may 
sense these as collision fragments and therefore may report them as 
network errors. 


To set the size of the frames to be generated 


1. Inthe Traffic Generator menu, move the highlight to Size= 
and press Enter. 


2. Inthe dialog box, write the length of the frame and press Enter. 


The length is written in decimal, in the same way that the Sniffer 
analyzer reports the lengths of captured frames: that is, stated as the 
total length but ignoring the physical header and trailer. 
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Delay Between Generated Frames 


The Delay option sets the amount of time the analyzer must wait after 
it finishes sending one frame until it can start to send another. The 
interval is the minimum interval between the transmitted frames. The 

actual delay may be longer, since the analyzer may have to wait its 

turn if other stations are transmitting. 


KO To set the delay between generated frames 


1. In the Traffic Generator menu, move the highlight to Delay 
and press Enter. 


2. Inthe dialog box, write the length of the delay (in milliseconds) 
and press Enter. 


The dialog box shows you the minimum and maximum values you 
can enter for the network the server is monitoring, as shown in Figure 
4-3. 


0.04 1.0 
1000 1000 


Minimum delay, milliseconds 


Maximum delay, milliseconds 


Figure 4-3. Minimum interval between consecutive frames sent by the 
traffic generator. 


Number of Frames to Generate 


The Frames option sets the maximum number of frames to be sent. 
(You can still tell the analyzer to stop sending before it reaches that 


number.) 
KAY To set the number of frames to be generated 


1. Inthe Traffic Generator menu, move the highlight to Frames 
and press Enter. 


2. In the dialog box, write the number of frames and press Enter. 


You can set any number of frames between 1 and 999999999, or write 
0 for infinite, which means that the server keeps transmitting frames 
until you press Esc to stop it. That’s the default. 


The Generated Frame’s Data Field 


The generated frame’s destination and source fields occupy the first 
twelve bytes. All the rest of the frame is considered “data.” You can 
specify what goes into the first 32 of the “data” bytes. The analyzer 


sii 
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inserts a counter in the last four bytes of the data field. Thus each 
generated frame is made up of fields as summarized in Figure 4-4. 


The number of bytes you specify 


Control Token ring only: two bytes of media access and 
frame control 


Source Six bytes, generated automatically by the server to 


identify itself. 


Destination | As you select from the list of destinations. 


Count The last four bytes, generated automatically by the 
analyzer (1 for the first transmitted frame of a 


series, increased by 1 for each thereafter). 


What's in between. The number of available data 
bytes is therefore 

Total—- (6 + 6+ 4 + (2 if token ring) ). 
Of these, you can specify the first 32 bytes. 
Any that you don’t specify are padded with 00 
hex. 


Figure 44. Fields of a generated frame. 


To specify the contents of the generated frames’ data field 


1. Inthe Traffic Generator menu, move the highlight to Data = 
and press Enter. 


Result: The analyzer opens a dialog box in which you may 
enter up to 32 bytes of data, in hexadecimal. 


2. Type the data you want. When the dialog box opens, the field 
initially contains 64 zeros (that is, 32 repetitions of 00 hex). Any 
positions you don’t specify remain as 0. Press Enter when your 
entry is complete. 


Result: The analyzer uses the bytes you specify to fill the first 
32 positions of the generated frame’s data field. 


If the total length of the data field is less than 32 bytes, the 
analyzer takes the number needed and ignores the rest. If the 
total length of the data field is greater than 32 bytes, the 
analyzer fills the additional space with 00 hex. 


The analyzer inserts the generated frame’s sequence number in 
the last four bytes of the data field. Thus, when the total length 
of the data field is less then 34 bytes, the sequence number 
overwrites those positions of the data field. 


If your generated frames are sent to a real station and you expect it to 
read them, it’s your responsibility to supply reasonable values in the 


el 
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first part of the data field. This is where an Ethernet recipient will 
expect to see an Ethertype, and an 802.3 recipient will expect to see 
length information and an 802.2 header. These are directly affected by 
the frame’s use of routing information. 


Effect of Routing Information on the Data Field’s Layout 


When a frame contains routing information (RI), the RI field starts in 
the third byte after the source address. But if there is no routing 
information, that’s the start of the 802.2 header or the Ethernet data. 


You can’t specify what goes in your first 32 bytes until you decide 
whether your generated frame contains routing information. 
Moreover, if it does contain routing information, RI is a field of 
variable length. You must declare its length correctly or your recipient 
won't be able to locate the fields that are supposed to follow. 


The hex characters you write 


specify the first 32 data bytes; that 


is, those that follow the 6-byte 
destination and 6-byte source 


The hex characters you write 
specify the first 32 data bytes; 
that is, those that follow the 1- 
byte access control, 1-byte 


address. frame control, 6-byte 
destination and 6-byte source 


address. 


If you checked the RI option, the 
variable length source routing 
information follows the first 2 
bytes of user-settable data. 


If you checked the RI option, 
the first of your 32 bytes 
contain the source routing 
information. 


Interpretation of the first 2 data 
bytes depends on whether you 
generate Ethertype or IEEE 802.3 
frames (see Figure 4-6). 


The first data byte (following 
the RI information, if any) 
identifies the destination SAP, 
and the second the source SAP. 
The next one or two bytes are 
control bytes indicating the 
type of transmission. 


Ethertype 802.3 


The first 2 data 
bytes are the 


The first 2 data 
bytes are the 
Ethertype. For | 802.2 length, 
example, 0800 | followed by the 
identifies the IP | variable-length 
Ethertype, RI field, 

while 0600 followed by the 
identifies XNS. | 802.2 header. 


Figure 4-5. Location of the specifiable data in a generated frame. 


The placement of the RI field within an Ethertype frame and within an 
IEEE 802.3 frame is summarized in Figure 4-6. 
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Based . 
Controlled by what you specify for first 32 bytes 


Destination Source Etype RI Data 
6 bytes 6 bytes 2bytes | 0-32 bytes Remainder 


rer Destination Source Length RI 802.2 header Data 
6 bytes 6 bytes 2bytes | 0-32 bytes 3—4 bytes Remainder 


Se 4-6. Position of RI field in Ethertype and IEEE 802.3 frames on 
Ethernet. 


RI Bit in the Source Address of the Generated Frames 


A frame originating on a token ring network may include source 
routing information, abbreviated as RI. The RI fields contain a record of 
each intermediate station that has forwarded the frame. The RI fields 
are located following the usual DLC source and destination fields. 
(For a more detailed description of the routing field, see “LAN Option 
to Interpret or Ignore the RI Bit in a Source Address” on page 2-6.) 


To indicate that these optional fields are present, the source address 
must be modified by forcing a 1 in the bit that (in a destination 
address) would indicate “broadcast.” You can’t control the source 
address of a generated frame. The generated fragment automatically 
has the source address of the Sniffer server that sent it. However, you 
can force the analyzer to insert the “RI present” bit. 


ON To turn on the RI bit in the source address of a generated frame 

1. Inthe Traffic Generator menu, move the highlight to Data. 

2. Move rightward to RI present. Press Spacebar to toggle xX 
(inactive) to / (active). 


If you elect to generate frames with the RI bit turned on, it’s your 
responsibility to include a consistent RI header at the beginning of the 
data you specify. 


Specifying the Length of the RI Field 


When the data you provide represent an RI field, you must specify the 
number of bytes the RI field occupies. The RI field (when present) 
starts with a two-byte header, followed by from zero to eight 2-byte 
segment addresses.! Thus the total length of the RI field may range 
from 2 to 18 bytes. The length (mod 32) is encoded in the low-order 
five bits of the first byte. 


1. These aren’t DLC addresses, but segment identifiers adopted by mutual agreement. 
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Running the Traffic Generator 


After you've specified the various parameters— 


¢ Destination 


+ Size 

* Delay 

* Quantity 
* Data 

* RI 


—you’re ready to tell the analyzer to start generating. 


To start the traffic generator 


Move the highlight to Traffic generator and press Enter. 


Result: The analyzer starts transmitting frames as directed. To report 
its progress, it displays a screen like that shown in Figure 4-7. It 
updates a counter showing the current frame number, and maintains 
two thermometer-style bar graphs of frames per second and Kbytes 
per second transmitted. 


TRAFFIC GENERATOR 


Sending frame 9461... 


Press ESC to sto 


40 60 80 
Frames per second from this station 


4 80 128 160 200 
Kbytes per second from this station 


Figure 4—7. Screen displayed at the console while a Sniffer analyzer is 
generating frames on token ring at 4 Mbps. 


While the Sniffer analyzer is generating traffic, it can’t perform any of 
its other functions as an analyzer. However, on a token ring network, 
it continues to forward incoming frames from its upstream neighbor. 


Running the Traffic Generator 


Appearance of the Transmitted Frames 


The format depends, of course, on the network. Each LAN frame 
starts with a header and DLC addresses appropriate to the network. 
Figure 4-8 shows the token ring frame whose transmission was noted 
in Figure 4-7, after it has been captured by another Sniffer analyzer. 
(On a different network, the frame would differ slightly, but would 
have the same general appearance.) 


The first two bytes are the AC and FC bytes of the standard DLC 
header, visible in the hex view as the characters 18 40. 


Six bytes of destination address follow (in this case, CO 00 FF FF FF FF, 
which means “Broadcast”). Then there are 6 bytes of source address 
(in this example, 40 00 65 01 00 01, which was the address of the 
sending Sniffer server). 


Then come the 32 bytes you specified for the frame’s data field. In the 
frame shown in Figure 4-8, the data field starts with 00 00 03 00 ... 00 
(On token ring, that’s the default that the analyzer automatically 
supplies. It remains in effect if you don’t supply your own values for 
the data field.) 


In the detail view, the server interprets the frame. The DSAP and 
SSAP fields are both 00. Since those do not match any protocol known 
to the server, it shows the protocol as ???. The server interprets the 
first 4 bytes as UI, and attaches the explanatory text “Unnumbered 
information.” 


In the hex view, the first 3 of those 4 bytes appear highlighted. (The 
fourth isn’t highlighted because the preceding bytes are sufficient to 
identify the UI command, and the protocol interpreter knows that UI 
makes no use of the fourth byte.) 


4-11 


Distributed Sniffer System: Analyzer Operations Manual 


Sequence Numbers 


5 Broadcast <A Sniffer 

5 Broadcast +A Sniffer r 
Broadcast <A Sniffer 22? DSAP=0 UI frame, 23 bytes 
Broadcast <A Sniffer 22? DSAP=02 UI frame, 23 bytes 
Broadcast <A Sniffer 22? DSAP=0 UI frame, 23 bytes 


FF FF FF 48 08 65 01 22 81 Wy 
$016 00 00 06 20 00 20 20 20 20 Ob oo 
8028 QB 24 FS 


Frame 33 of 247. 


Use TAB to select windows 
i 2 Set 4 Zoom  — mmoDisplugl/ Previll8 Next 1@ New 
~Helpii mark! ~in Menusiimmoptionsly frame—m™ frame capture 


Figure 4-8. A token ring frame generated by one Sniffer analyzer and 
captured by another. 


Following the standard header and whatever bytes you specify for the 
data field, the remainder of the frame consists of as many repetitions 
of 00 (hex) as necessary to fill out the total length you requested. The 
sequence number occupies the last 4 bytes. 


Each frame transmitted by the Sniffer analyzer’s traffic generator 
contains a sequence number. Each time you start the traffic generator, 
the sequence numbers start at 1. The frame’s last four bytes contain 
the sequence number. If the last four bytes overlap the first 32 data 
bytes, the sequence number overwrites some of the data you specified 
for the first 32 bytes. 


In Figure 4-8 you can see the frame number. It is encoded as a 32-bit 
unsigned integer, with the high-order bytes first. Thus, the decimal 
frame number that appears in Figure 4-7 as 9461 appears in the hex 
display (Figure 48) as 00 00 24 F5.! 


1. 24 hex = 36 decimal; F5 hex = 245 decimal. 


36 in the 256’s tages makes 9216. 
9216 + 245 = 9461. 
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CHAPTER FIVE: DISPLAYING AND INTERPRETING CAPTURED FRAMES bh 


General 


Chapter 5. Displaying and Interpreting 
Captured Frames 


Chapter Overview 


This chapter describes the various ways you can display and analyze 
the frames that you’ve captured. The Sniffer analyzer’s most 
important function —interpreting the various layers of protocol 
embedded in each frame— is an integral part of the process by which 
the analyzer displays the contents of the capture buffer. 


To select frames for display, the analyzer provides display filters. 
Their operation is much like the capture filters described in Chapter 2. 
During display, in addition to the various filters that operate during 
capture, the analyzer also offers filters based on the frames’ 
interpretation, such as filters for high level protocols or addresses. 


The Sniffer analyzer provides three formats for display, called 
summary, detail, and hex. The chapter describes the three views and 
their controls, and techniques for browsing through the captured 
frames. 


You can export reports on the selected frames in a variety of formats. 
One saves an edited trace file, limited to the frames you have selected. 
Others provide textual reports of the screen displays, or exported files 
in formats that can be imported by standard spreadsheet or database 
programs. 


This chapter doesn’t include the displays that are visible while the 
server is capturing; they’re described in Chapter 2. 


Role of the Capture Buffer in Display 


For the Sniffer analyzer to display or interpret them, frames must be 
in the capture buffer. If you’ve just completed a capture session, the 
frames you captured are in the buffer. You can start displaying them. 


Alternatively, you can load the capture buffer from a file of frames 
captured earlier. When you load the capture buffer from a file, frames 
from the file replace those in the buffer. If the buffer now contains 
frames that you haven't saved and don’t want to lose, save them toa 
file before loading the buffer with a new set. To save the current 
contents of the capture buffer to a file, or to load a saved file into the 
capture buffer, start from the Files menu; see page 5-69. 


To manage how frames are viewed, or to look at particular frames 
within the capture buffer, start from the Display branch of the main 
menu (see Figure 5-1). 


3 


Distributed Sniffer System: Analyzer Operations Manual 


Different Ways to View the Frames After You’ve Captured Them 


5—4 


The display menu first offers you a choice of four ways to view the 
captured frames. The options are: 


* Summary 

* Detail 

» Tiex 

* Two viewports 


You can see these options in the right panel of Figure 5-1. The figure 
shows the screen of an Ethernet Sniffer analyzer, but the display 
choices are the same for all networks. The options are not mutually 
exclusive; you can check any combination of them. By default, 
Summary is initially selected and the others are not. Each view is 
described later in this chapter. 


Server “Accting North"; F11 for list. F12 for menus 


NU 


i Cable tester 4d 
Network Traffic generator ¢ 
General Capture filters 

Trigger 


Capture #1] ¥ Summary 
Ethernet Sniffer | x Detail 
Network Analyzer lles x Hex 
Options x Two viewports 
Version 3.5 Exit < 
Filters 
(C) Copyright Print 
1986 - 1991 Manage names 


Display collected data. 


se the arrow keys to move, or ENTER to do this function——= 


10 New 
Help capture’ 


Figure 5-1. The display menu and its branches. 


The menu also offers a choice of filters to select frames for display, a 
print option for reports on selected frames, and an option to manage 
names to make displays more readable. You can see these choices in 
the lower portion of the right panel in Figure 5-1.! 


Once you've selected your display options, you're ready to start 
display 


1. “Manage names” would ordinarily fall below the lower edge of the panel, and wouldn't 
become visible until you scroll down. 


Setting the Display Filters 


To display the frames in the capture buffer 
I. Press F3. 


(Alternatively, move the highlight back to Display and press 
Enter.) 


The sections that follow describe the effects of the various display 
options. 


Setting the Display Filters 


Either before you start display, or as display proceeds, you can 
establish a display filter. Your display filter limits display to a subset 
of the frames in the capture buffer. Filtering doesn’t remove frames 
from the buffer, but omits them from the display. When some frames 
are skipped, the frames that remain visible have the same frame 
numbers as before. Thus, you may see frame 30 followed by frame 35 
because the display filter excludes frames 31-34. 


When you save the contents of the capture buffer to a file, you may 
choose to save all frames (regardless of the display filter) or just the 
frames that the filter accepts. 

KAS To set display filters before you start the display itself 


1. Inthe main menu, select Display. Then move the highlight 
rightward and then vertically to select Filters. 


2. Move the highlight vertically to the type of filter you want. 
Select (in turn, as desired): 


— Address level (page 5-7) 
— Destination class (page 5-8) 
— Station address (page 5-9) 
— Protocol (page 5-13) 

— Pattern Match (page 5-13) 


These are described individually later in this chapter, in 
sections beginning on the pages noted. 


It’s easiest to set up a display filter and to select your initial form of 
display before you actually start displaying frames on the screen. 
However, it’s not hard to alter your filters or your display options 
after you've started the display. 


IK a» To change filters or display options once display has started 


KK 


1. Press F6, Display options. 


= 
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Result: The server opens a temporary panel, superimposed on 
your current display. Make the changes you want. 


2. Press F3 to return to the display (as modified). 


You can see the display filters submenu in Figure 5-2. (The figure 
includes frame quality options that are available only on Ethernet.) 


Cable Tester | 4 Summary 
Traffic Generator +] x Detail 
Capture filters x Hex 
Trigger x Two viewports Address level 
Capture 4d Address filter 
Display 4 1s Protocol 
Files int ¢#| == Pattern Match 
Options Manage names 
Exit d J Good frames 
¥ Bad CRC frames 
’ Fragments 
Y Bad alignment 


Setup filters for frames to be displayed. 


Ise the arrow keys to move around in the menu 


il 3 Data 18 New 
Help display capture| 


Figure 5-2. The display filters menu. 


Criteria for Filtering 


The display filter permits the Sniffer analyzer to display a frame that 
meets all of the following criteria: 


Address level The frame contains an address in one of the 
indicated protocols. 


Destination class The frame contains a DLC address in the 
indicated class (such as broadcast or specific). 


Station address The frame contains any of up to four specific 
addresses at any of the levels selected by the 
address level filter. 


Protocol The frame contains one or more of the protocols 
marked witha /. 


Pattern filter The frame contains the logical combination of 
patterns you specified. 


= 


Address Level Filter 


Setting the Display Filters 


Frame defects (On Ethernet, StarLAN and PC Network only.). 
The frame exhibits: 
* No errors 
* Bad CRC 
* Fragment 
* Bad alignment 
—as you place a J beside the categories you want 
included in the display. 


Every frame contains both the address of the station from which it just 
came and the address of the station that is its immediate destination. 
These addresses are in the frame’s lowest level, usually DLC. 
Frequently a frame contains other addresses as well. For example, it 
may contain the address of the original source and the address of the 
ultimate destination. The data field of a lower-level frame thus may 
include a message written in a higher-level protocol, with its own 
source and destination, written according to that protocol’s rules. 


This is almost certainly the case for all frames on a synchronous 
communications link, and also very likely when frames are being 
relayed through a gateway between LANs. At the DLC level, a 
frame’s source and destination may be the stations responsible for the 
current leg of its journey. Within the DLC frame, there may well be 
addresses in embedded protocols such as XNS, IP, X.400, and so on. 


When you set an address level filter, you put a / beside one or more 
protocols in the panel to the right of address level. The filter accepts 
only those frames that are addressed in one of the protocols you've 

checked. To be included in the display, a frame must contain 


* A protocol from the indicated set of protocols 
and 
* An address in that protocol. 


Many protocols require that the frame include an address. But that is 
not universal. Where the protocol permits both addressed and 
unaddressed messages, an address level filter accepts a frame only 
when it actually contains an address. 


The Sniffer analyzer’s default address level filter has a check at the 
lowest level of protocol, but at none of the higher levels. Since every 
frame has a low-level address, the default accepts all frames. 


To set an address level filter for display 


1. Move the highlight to Display, then to Filters, then to Address 
level. 
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2. Move the highlight vertically among the listed protocols. Press 
Spacebar to toggle between J (include) and X (don’t include). 


— Puta check mark beside the protocols you want 


— Remove the check mark from the lowest level, and from 
other low levels you want to exclude. 


Effect on Displayed Names 


Effect on the Name Table 


The Summary view shows one address for each frame. When a frame 
contains multiple levels of address, the Summary view shows the 
highest of the levels you checked in the address level filter. Thus, if 
you put check marks at the lowest level and at some higher levels, that 
choice causes the Sniffer analyzer to accept all frames but makes the 
Summary display show higher-level addresses. When the name table 
contains a symbolic equivalent for that address at that protocol level, 
the Summary view shows the name instead of the numeric address. 


When you edit names (page 5-62), the name table includes an option 
to add a new station for each of the protocol levels checked in your 
address level filter. 


Destination Class Filter 


During display, the destination class filter permits you to include or 
exclude messages addressed (at any level) toa broadcast destination.! 
You can decide independently whether to include broadcast frames 
or frames with specific addresses. (Of course, if you exclude them 
both, you'll have nothing left to look at.) 


For each class that you include (broadcast or specific), you also specify 
the address level (or levels) to be included. The submenu for 
Broadcast and the submenu for Specific each contain a list of 
protocols at which an address may occur (Figure 5-3). By default, 
initially these are all checked (so that the destination class filter 
accepts all frames). You turn off the check marks for the levels you 
don’t want. The analyzer accepts a frame if it includes the desired type 
of address at any of the levels checked. 


1. Bycontrast, during capture the analyzer can filter for broadcast addresses oy at the DLC 


level. Since there are no broadcast addresses at that level on a synchronous 


nk, the 
WAN/Synchronous analyzer has no capture filter for destination class. 


5-8 


Setting the Display Filters 


Address level 


Destination class { x DLC 
Station address Y Specific Y XNS 
Protocol x 180 
Pattern match x X25 LCN 
x X25 Call 


x SNA 


Should broadcast frames be included? 


Press space to select (/) or not select (x); Alt-space inverts all. 


TE 
capture! 


Figure 5-3. Address levels within the “Broadcast” filter. 


KE To set a destination class filter for display 
Roy 

1. Move the highlight to Display, then to Filters, then to 
Destination class. 


2. Move the highlight to Broadcast or Specific. Press Spacebar to 
toggle between, / (include) and x (don’t include). 


3. Ifyou checked Broadcast, move rightward to the list of address 
protocols. Use the up or down cursor key to highlight a 
protocol you want to set. Pres Spacebar to toggle between ¥ 
(include) and xX (don’t include), or Alt-Spacebar to reverse the 
setting for all protocols. (If you leave Broadcast without a check 
mark, it doesn’t matter which protocols are checked in 
Broadcast’s submenu.) 


4. Similarly, if you checked Specific, move rightward to its list of 
address protocols, and set a check mark at each level that you 
want to include. (Note that, although the two lists contain the 
same protocols, your selections of broadcast protocols are 
independent of your selection for specific protocols.) 


Station Address Filter 


A station address filter is formed from some logical combination of up 
to four pairs of addresses. Address filters for display work just like 

address filters for capture, but with one important difference. During 
display, the addresses you specify can be at any of the levels that your 
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protocol interpreters recognize. (By contrast, a capture filter can 
consider only low-level addresses.) 


The procedure for setting an address filter for display is like the 

procedure for setting one for capture (described starting at page 2-13). 
However, there are a few additional points because a display filter can 
include addresses at any level. To review, the procedure is as follows: 


KA To set a station address filter for display 
1. Inthe display menu, select Filters. Then select Station address. 


Here you may enter from one to four matches, each of which 
may contain a single address or a pair of addresses. 


2. Move the highlight to the first match. Initially, it has the name 
Match 1. 


You can give a name to each of your four matches. The name 
has no effect on what the analysis server does. The match 
names just serve as mnemonic labels. 


To change the match’s name, move the highlight to Match 1 
and press Enter; see Figure 2-5, page Figure 2-5. 


Result: The server opens a dialog box in which you can supply 
a name for this match. 


From SERVER 4d 
Match 1 
Match 2 
Match 3 Y Reverse direction 
Match 4 
Others P exclude these 
Exclude these 


Match frames TO the designated station. 


Press ENTER to change the station: 


18 New 
capture} 


Figure 5-4. Menu to select a station address for the filter. 
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Setting the Display Filters 


3. To specify the source address for your first match, move the 
highlight to the entry to the right of Match 1. Initially, it says 
From <any station>. 


Press Enter. The analyzer opens a dialog box showing names 
and station addresses in the working copy of the name table. 


To select an address for your filter, scroll to the line that 
contains the address you want and press Enter. 


Result: The analyzer copies the highlighted address into the 
slot labeled From. Instead of saying From <any station>, it 
now says From <the address you selected>. 


As you scroll through the name table, notice that it contains addresses 
at various levels (see Figure 5-5). Sometimes the same address may 
occur at more than one level. When you choose an address, it’s 
important to place the highlight on the address at the level you want. 


SELECT STATION Level Address: 

<New station> DLC 

<New station> IP 

<New station> XNS 

<Any station> XXXXXXXXXXXX 
Intr1ng5924F 
$2070125924F 
NwkGn1220256 
NwkGn1 240001 
Intr1n@3E5C2 

ACCTG 19005A3826EF 

AppleTalk 128 ATALK =: 128 

AppleTalk 255 ATALK = 8.255 

Athens TS IP (192. 42.252.25] 

Atlantis Sun DLC Sun 76A83 

Atlantis SUN IP (192. 42.252. 28] 

BIZ-ONE XNS 190054122041 

ise t and | then press ENTER, or ESC to return. 


Figure 5-5. Dialog box in which to select a station address for display filters. 


It includes a new address entry for each protocol checked in the 
address level filter. 


4. Tospecify a destination address, move the highlight to To and 
press Enter. Supply an address in the same way as Step 3. 


5. To indicate whether this match also applies to traffic in the 
reverse direction, move the highlight to Reverse direction. 
Press Spacebar to toggle between J (include) and x (exclude). 
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6. To indicate whether frames identified by this match should be 


included or excluded, move the highlight to the radio control 
Include these or Exclude these, and press Spacebar at the one 
you want. 


Repeat steps 1 through 6 for up to four matches. 


To specify what the analyzer should do with frames not 
covered by your matches, move the highlight to Others and 
then to Include or Exclude, and there press Spacebar. 


Order in Which Matches Are Checked 


See “Taking Advantage of the Order in Which Matches are Checked” 
on page 2-17. Although it’s about address filters during capture, it 
applies equally to address filters during display. 


Adding Entries to the Working Name Table 


If the address you want isn’t yet in the name table, you must first add 
it to the table and then select it. There are two ways to add new 
addresses: 


Let the Sniffer analyzer scan the capture buffer and add new 
addresses automatically 


Add the new addresses manually. 


Automatic Scanning for New Addresses 


The easiest way to make sure that all addresses in the capture buffer 
are in the name table is to have the Sniffer analyzer scan the entire 
contents of the capture buffer. It does that automatically the first time 
you use display following capture (see page 5-65). 


Adding Addresses Manually 


Cy 


oy 


2. 


KA To supply a new address for a station address filter 
KO, 
as 


Highlight the line that says <New station> for the address level 
you want. 


The name table contains a <New station> entry for each of the 
levels checked in the address level filter. If the name table lacks 
a <New station> entry for the level you want, probably you 
haven't yet checked that level in the address level filter. Return 
to the address level filter, adjust it appropriately, and then go 
back to defining your station address filter. 


With <New station> highlighted, press Enter. 


Protocol 


Pattern Match 


& 


Setting the Display Filters 


3. The server opens a dialog box in which to write the address and 
a name for it. 


4. Press Enter. The analyzer records the name in its working copy 
of the name table and at the same time makes it the effective 
address of the match you are defining. 


Unnamed addresses are transitory 


The working name table lasts only until you exit the Sniffer analyzer 
program. You can save the name table by selecting manage names 
and then save names. But that only saves addresses that have names. 
Addresses that lack symbolic equivalents are dropped. Be sure you 
have assigned a name to each address you want to preserve. 


You can filter for frames that contain a protocol that interests you. Set 
a check mark beside the name of each protocol that you wish to 
include in the display. The filter includes a frame in the display when 
it contains any of the protocols you check. 


During display, the Sniffer analyzer can filter for any protocol that its 
protocol interpreters recognize. (However, during capture, the Sniffer 
analyzer filters only on the lowest-level protocols.) 


To select protocols for the display filter 


The procedure to mark protocols in the display filter is the same as the 
procedure to mark protocols in the capture filter (see the discussion 
starting at page 2-18). However, for display, the list of possible 
protocols is longer. That’s because it includes any of the protocols 
interpreted by your protocol interpreter suites, and not just protocols 
at the DLC level. 


A quick way to select only one protocol is as follows: 

* Move the highlight to the one you want. 

* Press Alt-Spacebar to change / to X for all protocols. 

* Then press Spacebar to change x to / for the protocol you want. 


You can set a filter to accept frames that contain a set of patterns. The 
set may be built from a logical combination of up to eight component 
patterns. Each component pattern is a specific sequence of characters 
at a specific location (each described as hex, binary, or text). 


To set up a pattern match filter for display 


The procedure for specifying a set of patterns for the display filter is 
exactly the same as the procedure for specifying a set of patterns for 
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Defective Frame 


the capture filter (see the discussion starting at page 2-19). The only 
difference is that, for display patterns, you highlight Pattern match in 
the Display filters menu rather than in the Capture filters menu. 


On Ethernet, the Display Filters menu includes four additional 
options. (They also appear in the Capture Filters menu.) The four are: 


* Good frames (that is, frames having none of the following 
defects). 


* Bad CRC frames. 
¢ Fragments. 
* Misaligned Frames. 


Ona WAN, the only filterable defect is Bad CRC. On token ring, the 
“monitor” interface card does not pass defective frames to the Sniffer 
server. 


To set filters for frame defects 


1. Inthe Display filters menu, move the highlight downward to 
the last section. 


Result: You'll see the list of defect categories for the network 
the analyzer is monitoring. A / mark indicates that frames in 
the category should be accepted, X indicates that they should be 
excluded. 


2. Move the highlight to each category you wish to change. Press 
Spacebar to toggle between / and Xx. 


Three Ways to View Frames 


There are three ways to view a frame. You can have just one view on 
the screen or any combination of the three. These views can be 
focused on a single frame in the capture buffer, or at two different 
frames. The three views are: 


Summary view A short form of the hexadecimal and Detail 
listings condensed so that each level fits on a 
single line. You may elect to show all levels of 
interpretation or only each frame’s highest level. 


Dual Viewports 


zoom 


Active Panel 


The Summary View 


Detail view The protocol is identified and standard fields 
within it are labeled and explained. Station 
addresses are replaced by their symbolic 
equivalents according to the address table you 
supplied in the default startup file (see page 6- 
10ff). Since a low-level frame may contain 
higher-level frames within it, a single frame may 
require several levels of interpretation. 


Hexadecimal view All bytes of the entire frame are shown, 
accompanied by a transliteration to ASCII or 
EBCDIC characters. 


How the three views are positioned 


When you have more than one view open, they’re always in the same 
order. Summary is always above the others. Hex is always below the 
others. 


In addition to these three views, you also have the option to split the 
screen vertically into two independent viewports. The two sides 
contain the same combination of Summary, Detail, and Hex. Having 
two viewports permits you to scroll independently on the left and 
right sides of the screen. That way you can keep a frame in view on 
one side while on the other side you scroll forward or back to look for 
related frames. 


To get an enlargement of one of the views, press F4, Zoom in. The 
active view then occupies the entire area, temporarily concealing the 
others. To return to the multi-panel overview, press F4 again. 


The view that contains the cursor is said to be active. The border of the 
active panel is shown intensified (brighter or in a contrasting color, 
depending on the monitor). The Tab key moves the highlight from 
one panel to the next, activating the panel in which it arrives. Shift Tab 
moves the highlight in the reverse direction. 


The Summary View 


The Summary view gives you a condensed view of your captured 
frames. Each is reduced to a single line or a few lines. The Summary 
view is the only view that shows several frames at once. Although 
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each frame is abbreviated and condensed, you can see at a glance the 
sequence and context of the frames. You can then examine individual 
frames in greater detail or skip over them. 


You have several choices on the Summary submenu (visible in the 
right panel of Figure 5-6). 


Cable Tester 4d 
Traffic Generator 4 
Capture filters 
Trigger Name width= 12 4 
Capture 4 ; 
Display dy Y Highest level only 
Files x Detal x Two-station format 
Options x Hex 
Exit x Two viewports x Flags 
x Absolute time 
Filters Y Delta time 
Print x Relative time 
Manage names x Bytes 
x Cumulative bytes 
x NW Utilization 


x Force Protocol 


Show the summary interpretation of frames. 


Press space to select (/) or not select (x) this option—== 
1 3 Data 10 New 
Help display capture} 


Figure 5-6. Options for the Summary display. 


Names in the Summary View 


Manufacturer IDs 


In the summary view, when the Sniffer analyzer knows a station’s 
name, it uses it. But when an address has no symbolic equivalent in 
the name table, the analyzer displays the station’s numeric address. In 
general, a numeric address is shown in the conventional format for its 
type. For example, a DLC address is shown in hexadecimal, but an IP 
address is shown as [n.n.n.n], and so on. 


On Ethernet or token ring, each station’s DLC address contains six 
bytes. Six bytes can be written as 12 hexadecimal digits. This is the 
default width of the name field in the Summary display for all Sniffer 
analyzers (regardless of network). 


Where the analysis server shows a 6-byte DLC address, it attempts to 
interpret the first three bytes as the name of the NIC’s manufacturer. 
When it is able to find the manufacturer's code in its table of 
manufacturers, it replaces the first six characters of the station address 
with an ASCII abbreviation of the manufacturer’s name. 


The Summary View 
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Higher-Level Addresses 


The file containing names for manufacturer IDs is named 
STARTUP.xxD (where xx stands for the two-letter network 
abbreviation (TR, EN, SY). See “Table of Manufacturer ID Codes and 
Abbreviations” on page 6-17. 


To have the Sniffer analyzer use higher-level protocol addresses 
instead of DLC addresses, you must check the desired protocol levels 
in the address level filter; see page 5-7. 


Width of the Name Field 


You may change the width of the name field in the Summary display. 
The name table permits names up to a maximum of 31 characters. If 
you use long names, you may want to make the name field wider to 
accommodate them. This may push some other fields off the screen, 
but you can always scroll sideways to see what's there. If you use an 
external screen, you may be able to display more rows or columns. 
The analysis server takes advantage of extra columns if they’re 
available. 


The name field’s smallest permissible width is six characters. When 
the display includes a name longer than the name field, the Sniffer 
analyzer truncates the name and replaces the last two visible 
characters with dots (to show that the name has been truncated). For 
example, if you squeeze the 10-character name FileServer into an 8- 
character field, it appears as FileSe.. (that is, six characters and two 
dots). 


Multiple Levels vs. Highest-Level Only 


You can toggle the option Highest level only. That is, either it’s 
checked or it’s not checked. 


Highest level only 


4 The Summary view shows only one line for each frame, 
summarizing the highest-level protocol that the frame contains. 


X | The Summary view shows a separate line for each protocol the 
frame contains.! The levels are arranged with the outermost 
(lowest) level on top. The protocols are color-coded by level (see 
Figure 5-18, page 5-33). 


1. In X Windows, there is a separate line for each protocol of each message within the frame. 


et 
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KX To display all levels of protocol in the Summary view 
KOA 1. Move the highlight to Display, then to Summary, then to the 


panel to its right. 


2. Move the highlight to Highest level only and press Spacebar to 
toggle from J (active) to X (inactive). 


Two-Station Format 


Analysis often focuses on the interchange between a pair of stations. 
To make the dialog clearer, use filters to show those stations only and 
elect two station format. Two station format shows transmissions 
from one station on the left side of the screen, and transmissions from 
the other station on the right. An example is shown in Figure 5-7. (In 
this figure, the display is shown with highest level only turned off, so 
there is a separate line for each level of protocol.) 


SUMARY—Delta t-From Konig—Fron G 
5 §.3208 DLC Ethertupe=0800. size=68 bytes 
IP. D=036.56.8.288] S=[36.53. a. 181] LEN=21 ID=30706 
TCP D=23 S=1842 ACK=2930184833 SEQ=43117349 LEN=41 
Telnet C PORT=1842 <@B> 


DLC Ethertype=088) B bytes | 
IP D=(36.53.8.181] S=[36.56.8.28 
a is 1042 $=23 ACK=43117350 


ype= e=68 by : 

IP D=(36.56.9. ny . 136. 53: iy 181) L 70 

TCP D=23 S=1042 ACK=2930104833 
DLC Ethertupe=@808, size=66 bytes | 
IP D=[36.53.8.181] S=[36.56.0.20 
TCP D=1042 S=23 ACK=43117358 
Telnet R PORT=1042 <1B>I<1B>Y6k8< 

DLC Ethertype=0800, size-60 bytes 

IP D=[36.56.8.208] S=[36.53.0.181] LEN=20 ID=30708 

TCP D=23 S=1042 ACK= 2930184844 | 

DLC Ethertupe=0800. size=62 bytes 

IP. D=(36.56.8.208] S-[36.53.0. 181) LEN=2 

TCP D=23 S=1042 ACK=2930104844 


2 Set Db 6Displygi’ Previi—g8 Next 10 New 
Helpl mark Menus foptionsg framei™ frame capture 


Figure 5-7. Two station format for the Summary view. 


In two station format, the source and destination fields are omitted. 
Instead, there are two columns, headed From xxx and From yyy. A 
frame from the station on the left is assumed be addressed to the 
station on the right, and vice versa. 


IAN To switch to Two-station format 


1. Move the highlight to Display, then to Summary, then to the 
panel to the right. 


2. Move the highlight to Two-Station Format. Press Spacebar to 
toggle between X (inactive) and / (active). 
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The Summary View 


3. Useful but not essential: set filters so that only the two stations 
of interest appear in the display. 


Which Stations Appear in Two-Station Format 


® 


The source that appears earliest in the capture buffer is shown on the 
left; the source that appears second appears on the right. 


To adjust the separation between the columns, change the width of 
the name field. To adjust the number of columns devoted to time 
displays, change your selection of time measurements (see Figure 5— 
8). To adjust the horizontal position of the display on screen, use the 
horizontal cursor position keys to scroll sideways. 


Frames that Don’t Fit the Two-Station Paradigm 


If your display filter accepts frames from other sources or with other 
destinations, the analysis server displays the additional frames in the 
usual format. That is, for those frames only, the display uses the full 
width, and shows source and destination explicitly. Since this is 
inconsistent with the two-station format, it’s usually preferable to 
combine two-station format with a filter that excludes other traffic. 


Options to Show Time, Network Utilization, and Frame Size 


For every frame, the Summary display permits you to include or omit 
various indicators of the time or the flow of data. The alternatives are 
listed in Figure 5-8 and defined in Figure 5-10. 


eu 
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; Whether 
Option Effect Required Geox ucts) 
Flags Widen flags field to 6 characters, to One col. No flags: 1 
allow for flags in addition toTandM. | required Flags: 6 
Frame Show unique serial number for each ; 1 
number | frame in the buffer. Required Biel) 


Absolute Show time at which the frame was 14 (+1) 
received 


time 
Show interval since the preceding , 
time displayed frame arrived. Optional 9 (+1) 


Byes Show length of this frame. 5 (+1) 
Cumulative | Show length of this frame and of all 6 (41) 
bytes frames between it and marked frame. ae 
u 
Network Show bytes in this frame as percent of | mutually 
usage theoretical capacity in the interval. exclusive. 


es Show interval since the marked 9 (+1) 
frame. 


Note: The entry 5(+1) means that the field assigns five columns for text followed by 
one blank column as a separator. 


Figure 5-8. Displays at the left side of the Summary view. 


Flags Option 
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The leftmost column of the Summary display always contains the T 
or M flags. When you select the flags option, the field is widened from 
one column to six. Flags appear as letters of the alphabet, left-justified 
in the field. Flags defined by the Sniffer analyzer are shown in Figure 
5-9. 


The Summary View 


M~ Mark. The reference frame for relative time 
y set the mark on n the current frame, press F2 


ed to the Sniffer analyze 


receding the fram 
verrun during transfe: 


Figure 5-9. Codes used in the flags field of the Summary display. 


Measures of Time, Network Utilization, and Frame Size 


To examine a network’s throughput, you need data on the volume 
and timing of transmissions. In its Summary display, the Sniffer 
analyzer provides several alternative measures of time and 
throughput, selectable to match the situation. You can include various 
combinations of these measures in the same display (see Figure 5-11). 
Additional measures require additional columns. This may push 
other parts of the display out of the visible portion of the panel, but 
you can always scroll to see the portion thus concealed. The measures 
are listed in Figure 5-10. 


Ee 
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Absolute time | When the Sniffer analyzer completes reception of a frame, it attaches a 
timestamp. The timestamp records the time according to the Sniffer 
server’s internal clock at the moment the Sniffer analyzer recorded the 
end of the frame. All displays of time are computed from the absolute 
value recorded with each frame. Absolute time is displayed as hours, 
minutes, and seconds to the nearest millisecond (on the token ring), or to 


the nearest tenth of a millisecond (on networks other than token ring). 
Delta time 


That's also how time is shown in the Detail display. 
Relative time 


The time shown is the interval between the current frame’s timestamp 
and the timestamp of the preceding frame in the display. Delta time is 
shown with the same precision as absolute time. Note that because it’s 
the interval to the preceding displayed frame, frames that are not 

displayed don’t affect delta time. 


The time shown is the difference between the current frame’s timestamp 
and the timestamp of the reference frame. Relative time is shown with the 
same precision as absolute time. The reference frame is marked by the 
letter M to the left of the frame number. When you first display the buffer, 
the first frame is marked. You can mark a frame (thereby removing the 
mark from any other frame) by pressing F2 while you have the frame 
highlighted. Once you’ve marked a reference frame, you can find it 
quickly by the display option Jump to mark (see 5-39). 


Bytes The number shown is the total number of bytes in the frame, not 
including the CRC frame. 


Cumulative The number shown is the sum of the lengths of the displayed frames, 
Bytes from the reference frame through the current frame (including both). 
When you haven't marked a reference frame, the Sniffer analyzer counts 
from the first displayed frame. 


Network The number shown is an estimate of the percentage of the network’s 
Utilization | bandwidth devoted to transmitting the displayed frame (and perhaps 
those preceding and following it). Basically, the measure is 


100 x bytes in all frames accepted during the interval 
Theoretical maximum that could be transmitted during the interval 


The interval is a time window centered around the frame. You can set the 
size of the interval to 1, 10, 100 or 1000 milliseconds. For example, if you 
pick 100 millisecond intervals, the utilization for a frame that arrived at 
13:27:06.100 is based on the number of bytes in frames whose arrival 
times ranged from 13:27:06.050 to 13:27:06.150. 


Utilization is a moving average. With a small interval, you'll see larger 
momentary fluctuations; a larger interval smooths them out. Any 
measure of network utilization must be based on a time window, 
whether described explicitly or not. Viewed without window averaging, 
a network is always either 100% busy (when a frame is being transmitted) 
or 0% busy (when no frame is being transmitted). 


ee 5-10. Descriptions of the optional displays for time, traffic, and 
ensity. 


Network 
General 


The Detail View 


Scrolling 


The Detail View 


SUMMARY—Abs Time——Delta T—Rel Time—Size—CumByt—DST——————SRC 
2112) 12:22:43.8995 6.6599 -1.1908 182 836 Sun 7972C+Intrlng5 
2113 12:22:43.9922 6.8927 -1.9072 654 Intrln@58CBé<Sun 97 
2114 12:22:44.0108 9.6185  -.9887 594 Broadcast +RND EN 
12:22:44.7011 6.6993 534 RND EN +RND PS 
12:22:44. 7825 ‘ : 474 +RND EN 
12:22:44. 7046 : : 368 +RND PS 
12:22:44. 7056 : : 302 +RND EN 
12:22:44. 7067 ; 2 214 +RND PS 
12:22:44 7682 ? . 148 +RND EN 
12:22:44 9995 t : «RND EN 
2:22:45. 104 . 1650 1058 j 
12:22:45.1919 F : Intr1n@58CB6+Sun 97 
12:22:45. 2598 k : Sun 07972C+Intr1ng5 
12:22:45 .3367 ‘ i Sun $7972C+Intr1ng5 
12:22:45. 3379 : ; Intr1n@58CB6+Sun 97 
12:22:45. 4648 ‘ : RND EN «Kate Tro 
12:22:45. 4788 : : Sun $7972C+Intr1ng5 
12:22:45. 481 ‘ f Intrln@58CB6+Sun 97 
12:22:45. 4811 ! : Kate Trous..«RND EN 
12:22:45. 483 ; RND EN «Kate Tro 


1 2 Set D __ mODisplufi7 Prev 10 New 
Help” mark Menusi™moptionsl™l frame capture| 


Figure 5-11. Display showing several measures of time. 


The Detail view presents a complete interpretation of a frame, 
labeling each field and decoding the value of the field’s parameters. It 
also shows certain information not contained within the frame, such 
as the time on the Sniffer server’s clock when the frame arrived. 


Figure 5-12 shows the text of a Detail display. The Detail view 
frequently requires many lines. On screen, you can scroll to the parts 
not immediately visible. Figure 5-12 shows the entire Detail, as it 
appears when you print it. The example is a TCP/IP frame 
transmitted over Ethernet, but the general format is similar for any 
network. The left margin of the Detail view indicates the protocol 
governing that portion of the interpretation. 


In any panel, when the information takes more space than can fit on 
screen, you can use the cursor keys to scroll hidden text into view. 
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: Frame 1 arrived at 11:20:37.4621: frame size is 68 (@03C hex) bytes. 
: Destination: Station 82608C063841, Host Port 4 

: Source : Station $2608C115176, Remo 26 

: Ethertype = 808 (IP) 


IP Header 


: Version = 4, header length = 28 bytes 
‘ ae of service = 2 
: routine 
normal delay 
normal throughput 
: normal reliability 
: Total leu = 42 bytes 
: Identification = 753 
: Flags = @X 
.. .... = may fragment 
: ..M. .... = last fragment 
: Fragment offset = 9 bytes 
: Time to live = 255 
: Protocol = 6 (TCP) 
: Header checksum = 6EDD (correct) 
: Source address = [36.53.9.195], Jackrs AST 
: Destination address = [(36.56.0.208], TS Monitor 
: No options 


: Source port = 4704 

: Destination port = 23 (Telnet) 

: Sequence number = 378 

: Acknowledgment number = 738299873 

: Data offset = 20 

: Flags = 18 
ie eee 


(No urgent pointer) 
Acknowledgment 
Push 

(No reset) 

(No SYN) 

(No FIN) 


mou ot oot 


: Window = 512 

: Checksum = 8AQD (correct) 
: No TCP options 

: [2 byte(s) of data] 


Telnet: 
Telnet : <QD><QA> 


Figure 5-12. Detail view of a sample frame. 


When you send the display to a printer, the SniffMaster console prints 
the entire text of the view (or views) you've selected, regardless of the 
boundaries of the screen.! 


ay pre reese how you've configured the console and server, the printer output may be 


redirected elsewhere. 
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The Detail View 


Eee 


Layers 


When a frame contains several levels of protocol, the Detail view 
interprets all the levels. The outermost (lowest) level appears first, 
and so on in order until the innermost (highest) level appears last. 


The Detail interpretation is often larger than can fit in the available 
panel on screen. In that case, you see only part of the display at a time, 
but you may scroll to bring other parts into view. 


When you use both Summary and Detail at the same time, the 
analyzer prepares a panel for each. The analyzer automatically scrolls 
the Detail view to match the Summary view’s highlight. When you 
use Summary with Highest level only, the server automatically 
scrolls the Detail view so initially it too shows the highest level. When 
you do not restrict the Summary view to Highest level only, the 
analyzer automatically scrolls the Detail view to match the level 
highlighted in the Summary. 


Controlling the Level Initially Displayed in the Detail View 


When you are looking at Detail without the Summary, you can still 
control the level to which the analysis server initially scrolls when you 
switch to a new frame. 


To set the level initially displayed in the Detail view 
1. Inthe Summary display, turn off Highest level only. 
Display frames in the Summary view. 


2 
3. Move the highlight to the level you want displayed first. 
4 


Return to Display Options. Make the Summary view inactive, 
and Detail active. 


As you move to a new frame, the analysis server automatically scrolls 
the Detail view to show the level that you last highlighted in the 
Summary view. (When it comes to a frame that doesn’t include the 
level you selected, it shows the next lower level that’s actually 
present.) 


Formats for Higher-Level Numeric Addresses 


In the Detail view, the analyzer shows the numeric form of each 
source or destination addresses, and also the name you've assigned to 
address, when it’s available in the name table. 


The format for numeric display of higher-level addresses is 
hexadecimal, except where there is an established convention for a 
different form. For example, a 4-byte IP address is shown as a 
succession of four decimal numbers separated by dots, with the entire 
number enclosed in square brackets. 
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When the analyzer displays an address, it picks a format appropriate 
to the level and protocol in which the address occurs. Some common 
examples are shown in Figure 5-13. 


N 
Token ring or Ethernet Seine 


Present in all frames and shown| Every frame is 
as twelve hexadecimal digits, | either 
corresponding to the 6-byte from DTE or 
address. from DCE. 
Example: 020701031EF7 
Where the Sniffer analyzer 
recognizes the first three bytes 
as a manufacturer code, it 
replaces them by a 6-character 
abbreviation: 


Example: Intrln031EF7 


Shown in the same format as 6-byte DLC addresses. 
(Although an XNS addresses may be the same as a 
DLC address, the analyzer does not attempt to 
interpret the manufacturer as it does for DLC 
addresses.) 


Represented byte by byte, but each byte is 
represented by its decimal value, a number between 0 
and 255. Successive bytes are separated by a dot, and 
the whole sequence is enclosed in brackets. 


Example: [(84.12.139.144]. 


DRP 
(DECnet) 
DDP 


(AppleTalk) 


Address represented by two decimal numbers, the 
area and the node number, separated by a dot. Each 
number is computed as the binary value after 
masking certain bits in the address. 


Example: 184.27 


Address represented by two decimal numbers, the 
network number (representing a 16-bit network 
address) and the node ID (representing an 8-bit node 
number), separated by a dot. 


Example: 1080.208 


Figure 5-13. Format of address, on selected networks and protocols. 


Other address levels and formats may be present, depending upon 
the optional protocol suites installed in the Sniffer analyzer. 


Network 
General 


The Detail View 


Transmission of 6-Byte DLC Addresses 


At the DLC level, every station on earth using 6-byte addressing has 
a unique address. To be more precise, a DLC address uniquely 

identifies a station’s network interface card. The first three bytes of a 
DLC address identify the interface card’s manufacturer. The IEEE has 
assigned codes to the various manufacturers. Each manufacturer uses 
the other three bytes to assign a unique identifier to each of its cards. 


Bits on the Wire vs. Bits in Memory 


Historically, the various network technologies have had different 
rules for converting bits “on the wire” to bits in computer memory. 
Some systems transmit each byte high-order-bit first and some 
transmit low-order-bit first. Suppose a byte of computer memory 
contains the value that in hexadecimal is written 87. In memory, that 
consists of the following bits: 


18268 6111 
8 7 


If you could see the sequence of bits transmitted along a token ring 
cable, you'd see that each byte is transmitted with the high-order bits 
first,1 0 0 0 0 1 1 1. However, if you could make the same 
observation on Ethernet, you'd see that each byte is transmitted with 
the low-order bit first. You’d see hex 87 gobyas1 110 0001. 


Ordinarily, these different ways of transmitting are completely 
invisible to any user or program. The interface card translates 
between bits on the wire and bits in computer memory. You only see 
bytes in memory, before they’ve been sent or after they’ve been 
received, but never while they’re in transit. When an Ethernet card 
receives the sequence 1110000 1, it turns that into hex 87, and the 
receiving station has the same value as the sender. Since (at the DLC 
level) sender and receiver must be on the same network and must use 
compatible equipment, a byte in the sender’s memory results in the 
same byte in the receiver’s memory. No one at either end need ever 
know in what sequence the bits within a byte were sent. 


Consequence of the IEEE standard 


When the IEEE assigned codes to the various manufacturers, it 
specified the sequence in which bits are transmitted on the wire. It did 
not specify what the sender or receiver would see in memory. For 
example, Network General Corporation was assigned a particular 
sequence of bits. To transmit that sequence on token ring, a Sniffer 
analysis server has in its memory the bytes 00 00 A6. But to transmit 


that same sequence on Ethernet, the server’s memory must contain 
the bytes 00 00 65. That’s because A6 with the bits of each byte 
reversed is 65. 
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Thus, to comply with the IEEE standard, a given manufacturer ID 
should translate to one number for Ethernet (or any other network 
using low-order-bit-first), and to a different number for token ring. 
(At present token ring is the only network using high-order-bit-first.) 
The tables that the Sniffer analyzer uses to interpret manufacturers’ 
codes make allowance for this. There’s one table for token ring and a 
different table for other networks. Beware, however, that some 
manufacturers do not follow the letter of IEEE law and use the same 
value in memory for both network types. 


Protocol Interpretation 


The Sniffer analyzer gets its ability to interpret protocols from several 
sources. Interpretation for protocols at the lowest level is included in 
the software that supports the type of network that the server 
monitors. Interpreters for higher-level protocols are available in 
suites. Each suite contains a number of protocols that are related or are 
likely to occur together. (See the list of protocol interpreter suites in 
Figure 1-6, page 1-22.) 


The interpreters from these different sources are linked into the 
Sniffer analyzer’s executable file when it is built. Each protocol 
interpreter registers its presence and facilities with the Sniffer 
analyzer; this permits each interpreter to be represented in the 
appropriate menus and displays. In the Detail view, at the left edge of 
every line, each interpreter shows an abbreviation indicating the 
protocol it is decoding. 


When you have both Detail and Hex views open, for each line of the 
Detail interpretation, the corresponding bytes in the Hex display are 
highlighted. In this way you can see together the actual bytes and 
their interpretation. 


While a common registration and display procedure applies to all the 
interpreters, the various interpreters are nevertheless essentially 
independent, just as the protocols themselves are essentially 
independent. Within each protocol, the fields displayed are those that 
make sense within the context of the protocol. 


Bit-Level Interpretation 


A protocol may record binary attributes as individual bits packed 
within a single byte. Where that is done, the interpreters often explode 
each byte to show its eight bits separately. To illustrate, Figure 5-14 
shows the interpretation of hex IF at a particular position in the 
Banyan VINES protocol called VIP. Figure 5-15 shows an 
interpretation of the sequence 6B 80 00 from an IBM SNA header. This 
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Protocol Interpretation 


sort of decoding interprets not only the meaning of each bit set at a 
certain position, but also the meaning of each bit not set (that is, each 
Q). Bit-level interpretation is included in almost all protocols; 
however, in X Windows it is not universally shown, because the 
number of possible bit-encodings is extremely large. 


VIP: Transport control = iF 
VIP: £8 = Unused 
. = Do not return metric notification packet 
: = Return exception notification packet 
cc ae Hop count remaining (15) 


= 6B 
= Command 
= RU category is session control f 
... = Format indicator 
. = Sense data are not included 
= Only RU in chain 
= 89 
= Definite response requested 
= Response bypasses TC queues 
A: ee Pacing indicator 
> RH “byte 2 = @ 
A: ) = Begin bracket indicator 
. = End bracket indicator 
_ 8 = Conditional end bracket indicator 
. = Change direction indicator 
. = Character code selection indicator 
.. = Enciphered data indicator 
. = Padded data indicator 


Figure 5-15. Bit-by-bit interpretation of three SNA bytes on token ring. 


Alternate Displays for ASN.1-Encoded Protocols 


ISO protocols at the presentation and application levels can be 
interpreted in two modes. Each is written so that it conforms to a 
general syntax specified in ASN.1 (Abstract Syntax Notation 1, ISO 
8825). The individual protocols then assign meanings to the 
components identified by the ASN.1 syntax. To accommodate this 
dual level of interpretation, the ISO protocol interpreter suite gives 
you the option to interpret frames in these layers in either of two 


ways: 

Syntactic The Sniffer analyzer labels the ASN.1 components 
within each frame, or 

Semantic The Sniffer analyzer interprets what the various 


ASN.1 statements mean, according to the rules of the 
particular protocol in which the ASN.1 statements 
occur. 


= 
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When you select interpretation at the X.400 level, you get the semantic 
interpretation. To see ASN.1 interpretation, turn off X.400 in the 
protocol display filter. 


Figure 5-16 shows the same fragment of an X.400 frame interpreted 
first for ASN.1 syntax and then for its content as part of a P1 message 
envelope. 


= X.4@@ Message Transfer Protocol (P1) -- 
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5. 
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5. 
3. 
4. 
5. 
6. 
qs 
6. 
T., 
6. 
5 
6. 
6. 
3, 
4. 
5, 
5. 
6. 
6. 
2: 
3. 
3. 


Context-Specific Constructed [8], Length= Indefinite 
SET fof], Length=Indef inite 

Application Constructed [4], Length=Indefinite 
Application Constructed [3], Length=Indefinite 
Application Constructed [1], Length=Indefinite 
PrintableString, Length=2, Value = "US" 

Application Constructed (21, Length= Indefinite 
PrintableString, Length=7, Value = "ATTMAIL" 
PrintableString, Length=5, Value = "KANJI" 
1A5String, Length=19, Value = "VAX 888726 14:53:53" 
Application Constructed [8], Length=Indefinite 
SEQUENCE Cof], Length= Indef inite 

Application Constructed [1], Length=Indefinite 
PrintableString, Length=2, Value = "US" 

Application Constructed [2], Length=Indefinite 


PrintableString, Length-7, Value = "ATTMAIL" 
Context-Specif ic Constructed [2], Length= Indefinite 
PrintableString, Length=5, Value = "KANJI" 

Context-Specific Primitive [3], Length=3, Data = "VAX" 
Context-Specific Constructed [5], Length=Indefinite 
Context-Specific Primitive [8], Length=7, Data = "FRASIER" 
Context-Specific Primitive (1], Length=5, Data = “ALLEN” 
Context-Specific Primitive [2], Length=1, Data = "D" 


Application Constructed [5], Length=Indefinite 
Application Primitive [6], Length=1, Data = "<@2>" 
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1 
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1 
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2 
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2 
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1 

1 

1 

2 

1 

3 

1 

4 

5 

1 

2 

3 

3 

1 

4 

5 

6 Application Primitive [7], Length=1, Data = "<@2>" 
7 Application Primitive [8], Length=2, Data = "<@3CA>” 
8 Context-Specific Constructed [2], Length=Indefinite 
1 SET Cof], Length=Indefinite 

1 Application Constructed [8], Length=Indefinite 
1 SEQUENCE Cof], Length=Indefinite 

1 Application Constructed [1], Length= poe 
1 PrintableString, Length=2, Value = "U! 

2 Application Constructed [2], Length= Tidef inite 
1 PrintableString, Length=7, Value = "ATTMAIL" 

3 Context-Specific Constructed [2], Length=Indefinite 
1 PrintableString, Length=5, Value = “kanji” 

4 Context-Specific Primitive [3], Length=3, Data = 
5 
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2 
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1 
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1 

2 
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1 
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3 
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1 
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2 

1B 
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1 
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2 
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Context-Specific Constructed [5], Length=Indefinite 


Context-Specific Primitive [1], Length=7, Data = “roberta” 
Context-Specific Primitive [8], Length=1, Data = "<@1>" 
Context-Specific Primitive [1], Length=2, Data = "<@ZA8>" 


SET Cof], Length=Indefinite 

Application Constructed [#1], Length=Indefinite 
SEQUENCE Cof1, Length=Indefinite 

Application Constructed [1], Length=Indefinite 
PrintableString, Length=2, Value = "US" 
Application Constructed [2], Length=Indefinite 


PrintableString, Length=7, Value = "ATTMAIL 
Context-Specific Constructed [2], Length= Indefinite 
PrintableString, Length=5, Value = “kanji” 
Context-Specific Primitive [3], Length=3, Data = “sun” 
Context-Specific Constructed [5], Length=Indefinite 
Context-Specific Primitive [8], Length=7, Data = “frasier” 
Context-Specific Primitive [1], Length=5, Data = “allen” 
Context-Specific Primitive [8], Length=1, Data = "<82>" 
Context-Specific Primitive [1], Length=2, Data = "<@@D2>" 


Application Constructed [9], Length=Indefinite 
SEQUENCE Cof1, Length=Indefinite 

Application Constructed [3], Length=Indefinite 
Application Constructed [1], Length=Indefinite 
PrintableString, Length=2, Value = "US" 
Application Constructed [2], Length=Indefinite 
“ATINAIL” 


PrintableString, Length=7, Yalue = 
"KANJI" 


PrintableString, Length=5, Value = 
SET Cof], Length=Indefinite 
Context-Specific Primitive [8], Length=17, Data = 
Context-Specific Primitive [2], Length=1, Data = "<@%> 

Application Constructed [38], Length=Indefinite 
SEQUENCE Cof], Length=Indefinite 
PrintableString, Length=3, Value = 
SET Cof], Length=Indef inite 
Context-Specific Primitive [8], Length=17, Data = 
Context-Specific Primitive [2], Length=1, Data = "<>" 
Constructed OCTET STRING, Length=Indefinite 
OCTET STRING, Length=2848, Value = 

"<AB8B>1<82>k<80>* <82>0<80>a<801302>US<B000>...” 

2 OCTET STRING, Length=85, Value = 
" <PUDBLEDDAAL BOO AR AA ORB OAD AAARoo DAA AnooooosAAAee> 


"VAX" 


Context-Specific Primitive [8], Length=3, Data = "<S4A020>" 
Application Primitive [18], Length=15, Data = "880726 14:53:53" 


Context-Specific Primitive (#1, Length=8, Data = “danville” 


Protocol Interpretation 


: -~ X.40% Message Transfer Protocol (P1) --- 


: MPDU type = User (length = indefinite) 
: Envelope: 
: MPDU identifier: 
/C=US/ADMD=ATTMAIL/PRMD=KANJI/, VAX 888726 14:53:53 
: Originator: /C=US/ADMD=ATTMAIL/PRMD=KANJI/O=VAX/ 
PN=FRASIER. ALLEN. D/ 

: Original encoded information types: 
: Basic information type = A02B 

1 = Undefined 
. = No tLx 
= TA5Text 
= No g3Fax 
= No tIF@ 
= No tTX 
. = No videotex 
= No voice 
; = No sFD 
Shick ae cue he ab cat NO CIEL 
: Content type = 2 (P2) 
: UA content id = 880726 14:53:53 
: Priority = 2 (Urgent) 
: Per message flag = CO 
ce = Disclose recipients 


~ 
a 
S 
i) 


. = Conversion prohibited 

= No alternate recipient allowed 

...8.... = No content return request 

: Recipient info: 

: Recipient: /C=US/ADMD=ATTMAIL/PRMD=kanj i/0=sun/ 
PN=danville.roberta/ 

: Extension identifier = 1 

: recipient flag = A8 

: = responsibility flag on 

.... = basic report request 

1... = basic user report request 

: Recipient info: 

: Recipient: /C=US/ADMD=ATTMAIL/PRMD=kanj i/0=sun/ 
PN=frasier .allen/ 


>< >< >< >< >< >< >< >< DK DK DK DK DK OK OK OOK OK OOK OOK OOK OOK OD 


>< >< >< > > > OK 
> 
i= 
i) 


X48: Extension identifier = 2 

X.40@: Per recipient flag = Dd 

RAMs Dine i ena = responsibility flag on 

X.400: .18. .... = confirmed report request 
X.408: ...1 8... = confirmed user report request 
X.400: Trace information: 

X.4@8: Global domain identifier: /C=US/ADMD=ATTMAIL/PRMD=KANJI/ 
X.4@0: Arrival = 26 Jul 1988 14:53:58-0708 
X.402: Action = @ (Relayed) 

X.4@8: Internal trace info: 

X.4@0: MTA name = VAX 

X.400: Arrival = 26 Jul 1988 14:53:58-6708 
X.4@0: Action = ® (Relayed) 

X. 406: 


"880726145358-0708" 


"888726145358-8708" 


Figure 5-16. ASN.1 syntactic and semantic interpretations of the same 
X.400 layer of an ISO frame. 
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Token Ring “Address Recognized” and “Frame Copied” Bits 


Frame copied 


Address recognized 


As each frame circulates on the token ring, it has two extra “trailer” 
bytes at the end. The trailer is used to check the frame’s validity. It 
isn’t usually considered part of the frame, and doesn’t appear in the 
Hex view. However, the Detail view reports the status of two 
indicators in the trailer: the address recognized bit and the frame 
copied bit. They’ re visible in Figure 5-17 as part of the Detail view’s 
DLC report. 


Frame 35 arrived at 17:18:2§76; frame size is @@6F (111 decimal) byt 
AC: Frame priority 8, ReservatSgp priority 8. Monitor count 8 

: LLC frame, PCF attention cotW& None 

“Addr recognized indicators: 00, Frame copied indicators: 00 
Destination: Station 402020000002, Harrys PC 

Source : Station 400000000201. Newman 


Format identification (FID) 


Transmission header flags = 2D 

O01 .... = Format identification is type 2 
. 4t.. = Only segment 
Frame 35 of 22 


Ky 6Displugi/ Previi8 Next 
Menusimoptions™ framefil frame} 


1 2 Set 10 New 
Help § mark capture 


Figure 5-17. Detail view showing token ring “address recognized” and 
‘Fastie copied” bits. 


When a station recognizes itself in the frame’s destination, it sets the 
address recognized bit. If that bit is on when the frame reaches you, at 
least one station upstream from you has recognized itself as a 
recipient. (A frame sent to a functional address may have any number 
of recipients.) 


When a station retains a copy of the frame, it sets the frame copied bit. 
Normally, a recipient both recognizes and records the frame, and sets 
both bits. 


The values you see for addressed recognized and frame copied depend on 
where you are located. If a frame reaches you with address recognized 
already set, the frame must have reached the recipient before it 
reached you. When you’re looking for problems at a particular 
portion of the ring, you may wish to capture from different positions. 
The address recognized bit provides evidence of your position in the 
ring sequence. To verify that a station has accepted frames addressed 
to it, you have to be upstream from the sender and downstream from 
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The Hexadecimal View 


the recipient. (That is, you must not be between the sender and 
recipient in ring order.) 


Use of Color 


Except when the SniffMaster console lacks a color display, each layer 
of protocol has its own characteristic shade. 


Where possible, each layer is identified with one of the seven layers of 
the OSI model. (However, many protocols predate the OSI model, and 
don’t fit into it very clearly.) The Sniffer analyzer assigns colors to the 


layers as shown in Figure 5-18. 
1 Magenta 


Physical level protocols 
Red 


Fragmentation protocols 


Brown 


Link level protocols 


Green 


Network level protocols 


Yellow 


Transport level protocols 


Session level protocols Light green 
Presentation level protocols Light cyan 
Application level protocols I Light red 


Application level protocols II Light magenta 


Name protocols and network 
management layers 


Cyan (blue-green) 
Black 
Light blue 


Various protocol glue layers 


Other 


Uninterpreted data Gray 


Figure 5-18. Foreground colors to layers of the OSI model. 


Normal color displays use a blue background. Highlighted areas have 
a light-blue background. However, highlighted portions of a 
hexadecimal display have white backgrounds. 


The Hexadecimal View 


The Hex view displays each byte as two hex characters, 00 to FF, with 
a blank between successive bytes. The bytes are arranged 16 to a row 
in a full-width table (8 to a row in the half-width table for two 
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Text Transliteration 


viewports). At the left, the offset from the beginning of the frame is 
displayed in hexadecimal (Figure 5-19). 


AA 02 03 01 13 1B 02 60 
$1 2D BA 19 O8 8 1D 11 
82 84 22 35 BB 35 B1 19 
20 £9 20 28 20 28 04 73 
66 6F 72 64 83 65 64 75 
69 6C 88 73 74 61 6E 66 
20 2D 00 01 02 BB A8 CH 
30 38 30 05 57 41 49 54 
00 A8 CO OB 11 BA 20 20 
20 28 28 81 08 B1 CB 23 
O0 BA BA 20 28 BB 11 Ot 
00 21 00 OH A8 CB BO 11 
40 24 00 20 22 08 61 08 
QO AB CO 2B BA 24 24 00 
23 20 1 28 1 20 BB A8 
23 20 01 06 01 20 BB AB 
23 20 OF 20 01 28 20 A8 
69 6C 8 53 74 61 6E 66 
CB 23 08 OD 00 01 20 20 
54 53 @8 44 45 43 2D 31 


2 Set 
mark 


8C 06 38 41 28 28 45 20 
6C 44 24 35 BO BA 80 28 
93 E4 00 A6 84 88 02 B1 
61 69 6C 08 73 74 61 6E 
00 00 FF O@ 01 84 73 61 
6F 72 64 83 65 64 75 BB 
O90 OF 08 44 45 43 2D 31 
53 CO 23 20 OB 20 01 20 
OB 06 B1 44 45 48 84 20 
02 OB OO B1 22 08 AB CB 
48 28 22 84 CB 23 08 OB 
24 24 O0 C2 06 O1 44 45 
O1 CO 23 20 OB 20 O1 20 
C2 11 O1 40 20 28 24 CB 
CB 26 24 24 24 BO C2 CO 
CH 20 04 BA 28 28 OB CH 
CO O2 15 O0 BA 04 53 61 
6F 72 64 23 45 44 55 20 
A8 CO 20 OF @5 57 41 49 
30 38 30 AF 


Frame 35 of 97 


oD 6Displug/ Prevgm™s Next 
Menusmmmoptions™ framef™ frame 


4 

il. Stanford. EDU. 
wt WAI 
TS .DEC-1080. 


18 New 
capture 


Figure 5-19. Hexadecimal view of a TCP/IP frame on Ethernet. 


To the right of the hexadecimal codes, the Hex view shows the 
corresponding ASCII or EBCDIC characters. A standard character is 
shown by its text equivalent; anything else is represented by a dot. 


The transliteration of characters follows either ASCII or EBCDIC 
conventions. For Ethernet, the Hex menu includes a radio-control 
with two choices: 


ASCII characters 
EBCDIC characters 


The default is ASCII. The choice applies to all levels of all frames. 


To select ASCII or EBCDIC transliteration 


i 


In the main menu, select Display, then Hex, then move to the 
panel to the right of Hex. 


Move the highlight to ASCII or EBCDIC and press Spacebar. 


That moves the |» to the highlighted line. 


Dynamic Choice of Transliteration 
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On token ring or WAN/synchronous link, the menu includes a third 
choice: Dynamic. It’s the default. 


Windows, Views, and Scrolling 


EBCDIC characters 
Dynamic mode 


, ASCII characters 


WAN/Synchronous Dynamic Transliteration 


When you select Dynamic mode, the transliteration depends on the 
packet type set in the Options menu. When packet type is SDLC/ 
SNA, transliteration is EBCDIC. Otherwise, it’s ASCII. 


Token Ring Dynamic Transliteration 


When you select Dynamic mode, the Sniffer analyzer decides 
separately for each frame whether the frame should be transliterated 
as ASCII or EBCDIC. It gives you EBCDIC display of all MAC frames, 
and of any LLC frame whose SAP indicates that it contains SNA. It 
gives ASCII display of all other frames. 


Windows, Views, and Scrolling 


When you display two or three views at once, panels in the active 
viewport scroll together. For example, when you're displaying both 
Summary and Detail, you might scroll the Summary view so that it 
shows the next frame. That causes the Detail view to show the next 
frame also. The views remain in step. 


Similarly, when you shift the highlight in the Summary view to mark 
a different frame, the viewport’s Detail view and its Hex view both 
scroll automatically, so that they show the frame highlighted in the 
Summary view. 


When you're showing multiple levels within the Summary view, the 
report on a single frame may occupy several lines (one for each level). 
You can move the highlight from one level to the next, yet remain 
within the same frame. For example, you might move the highlight 
from the DLC level to the level above. When you do that, the Detail 
view also scrolls. The level at the top of the Detail view matches the 
level you've highlighted in the Summary view. 


Highlighting Detail in the Hex View 


When you display both Detail and Hex views, as you move the 
highlight in the Detail view, the Sniffer analyzer highlights the 
corresponding bytes in the Hex view (Figure 5-20). That makes it easy 
to match a sequence of bytes with its interpretation. 
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/type flags = 
: FM profile flags = 13 
SNA: TS profile flags = 87 
Primary LU cars flags 


= BO 
= Multiple RU chains allowed from primary LU 
. = Immediate request mode 


EBCDIC— 

0000 10 40 40 00 00 OO 00 02 40 OO 00 00 OO 1 0484. 

0018 O68 08 2D BO Oi B1 OB BC 6B 8H 04 a OB 13- OF BO. eee eccte ae | Fee 

0026 BO DO Bi 02 8 85 85 8B O2 06 O2 WY OO OO OO OO 3...00......... 

0030 00 00 0 20 00 OO 08 E2 C5 D5 C4 D3 E4 48 48 25... SENDLU 

0048 98 09 02 D5 D6 D9 D4 Ci D3 40 40 09 03 OO 28 0 NORMAL ..... 

9058 60 OD 06 06 OO OF 04 D5 C5 E3E6 D6 D9 D2 4BE2 ....... NETWORK .S 

9068 C5 D5 C4 D3 E4 OB 08 DI C3 E5 D3 E4 48 48 48 ENDLU. .RCVLU 


Use TAB to select windows 


2 Set 4 Zoom 6Displyg/ Previa Next 
~ mark | in loptions™ frame—m frame 


fl 10 New 
capture 


Figure 5-20. Synchronized highlighting in the Detail and Hex views. 


The Hex view shows the offset to the start of each line. You can readily 
calculate each field’s address. The hexadecimal offset is required 
when you describe a pattern to be matched. However, you can use the 
Cursor Up key to “cut and paste” from a displayed frame, without 
having to type the hex offset yourself. 


Detail and Hex Display of Spanned Frames 


In some protocols, a message at one of the higher levels may span 
several DLC frames. (See Figure 2-24, page 2-38.) During display, the 
Sniffer analyzer’s Detail view reassembles the entire high-level 
message as if the whole message were in the first frame. You can read 
the message continuously without having to jump among the 
separate frames that contain its parts. When you highlight a part of 
the Detail display, the Hex view continues to highlight the 
corresponding hex characters. 


Figure 5-21 illustrates the treatment of a spanned high-level message. 
Here are some points to observe: 


* Inthe summary view, the frame in which the high-level 
message starts has a note telling you how many frames the 
message spans. In Figure 5-21, the note says ISO_TP Data EOT 
(5 frames). In this example, the ISO TP data was split among 
frames 15, 16, 17, 18, 19 and 20. There’s no presumption that 
spanned frames are consecutive; unrelated frames might have 
arrived between them and so appear interspersed in the 
display. 


om 


Windows, Views, and Scrolling 


* In the Detail view, the entire high-level message is displayed 
as though all of it were in the frame in which it starts. When 
you print the display, the entire high-level message appears 
without a break, taking as many lines as necessary. On screen, 
you can see the rest of the message by scrolling within the 
Detail view. 


* Scrolling within the Detail view (as usual) causes the Hex view 
to scroll automatically. The field you highlight has a 
corresponding highlight in the Hex view. 


* The frame number in the Hex view doesn’t necessarily match 
the frame number in the Detail view. In Figure 5-21, the 
interpretation of ISO Session Layer is part of the Detail view of 
frame 15, because that’s where the ISO TP data starts. 
However, the corresponding Hex view shows frame 17. That’s 
because (although the message started in frame 15) its ISO 
Session Layer is in frame 17, starting at offset 36. 


* When the field highlighted in the Detail view extends over 
additional frames, the Hex panel scrolls to the start of the field, 
but adds a + sign to show that there’s more present in a 
different frame. A plus is visible in the last row of the Hex view 
in Figure 5-21. 


SUMMARY—DST—SRC 
LSS EBM DLC Ethertype=2802. size=62 bytes 
IP D=£192.9.208.193] S=£192.9.208.178] LEN=26 ID=5203 
TCP D=182 S=1882 ACK=38911 SEQ=106582@ LEN=6 WIN=4 
ISO TP Data EOT (5 frames) 
SESS Give Tokens, Data Transfer 
Frame 15 of 293 


ISO Session Layer -~--- 


: SPDU type = 1 (Give Tokens) 
: SPDU type = 1 (Data Transfer) 
: Length of SPDU parameter field = 3 


Frame 15 of 283 
$8 68 20 G1 DA 53 88 OB 14 51 87 36 B28 BB 45 OD 
96 2A 13 8D OB OB 3C G6 59 C2 CH B9 CB AA CO 89 
C8 Ci 24 3A O80 66 80 19 43 63 BO BO 97 FF 5Q 18 
16 08 AD 38 00 20 WGA 00 1F 02 FO 

Frame 17 of 283 


Use “ to select sates 


i 2 Set 4 Zoom 6Displug/ Prevails Next 
Helpl mark in ee fot one framemm™ frame capture 


Figure 5-21. Detail and Hex display of a spanned ISO frame. 
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Function Keys Available During Display 


During display, the following function keys are active: 


5-38 


Fl 
F2 


F3 


F4 


F5 
F6 


R7 


Help. Provides assistance in using the Sniffer analyzer. 


Set mark. Marks the reference frame with an M. The values 
reported by relative time and cumulative bytes count from the 
marked frame (see page 5—22). 


Display. When display has been interrupted (for example, by 
pressing F6 to change the display options), F3 is enabled. 
Pressing it resumes display. 


Zoom in/out. Temporarily expands the active panel to fill the 
entire window. When several panels are open at once, the space 
for an individual panel may be too small to show much. Pressing 
F4 zooms so that the active panel has the entire window. The 
other panels are concealed. Pressing F4 a second time restores 
the tiled arrangement of the open panels. 


Zooming enlarges all the panels, but places them one above 
another so you only see one at a time. You can still use the Tab 
key to move to the next open panel, which then gets the whole 
window. 


Menus. Returns you to the main menu. 


Display options. Provides you with the basic set of display 
options found in the Sniffer analyzer’s main menu. It also offers 
several auxiliary options, permitting you to: 


— Go directly to a specific frame number. 
— Search for a text string. 

— Search for a pattern ina frame. 

— Jump directly to the marked frame. 

— Jump directly to the trigger frame. 


See the following section, Searching and Jumping, for 
further information on these choices. 


Previous frame. Takes you to the previous frame. Only frames 
that pass the current display filter are shown, so pressing this 
key takes you to the adjacent visible frame, perhaps skipping 
over one or more that the filter has rejected. 


In asummary view that shows several frames at once, F7 (or the 
Cursor Up) moves to the preceding line (either the preceding 
frame or the preceding level of the current frame). It does so by 
moving the zone that is highlighted and scrolling if the highlight 
is already at the top or bottom of the panel. 


Function Keys Available During Display 


In the Detail view and the Hex view, F7 replaces the current 
display with the display for the preceding frame. 


If you have multiple views within a viewport —that is, summary, 
Detail and hexadecimal— when scrolling takes you to another frame, 
your hexadecimal or Detail views (if open) move to that frame, too. 


F8 


F10 


Next Frame. Pressing F8 (or the Cursor Down key) takes you to 
the next line or the next frame in the same way that F7 takes you 
to the preceding line or frame. 


New Capture. Starts the capture process again. 


Cursor movement keys 


tT Scrolls to the preceding line of the display. 

4 Scrolls to the following line of the display 

« Scrolls the display so 8 columns to the left are brought into view. 

+ Scrolls the display so 8 columns to the right are brought into 
view. 

PgUp Scrolls to the preceding page of the display. 

PgDown Scrolls to the following page of the display. 

Home Jumps to the top of the display. 

End Jumps to the bottom of the display. 

Tab Moves to next panel. 

Shift Tab Moves to previous panel. 


Searching and Jumping 


When you press F6 during display, you get a menu of display options 
superimposed on your current display. It includes several ways of 
searching and moving rapidly to particular frames (Figure 5-22). 


Kr 
O67, 


Jump to mark Jumps to the frame marked M. (If you haven't yet 
marked a frame, the first frame is marked.) 

Jump to trigger Jumps to the frame marked T. 

Go to Frame Moves directly to a frame whose number you 
know. 


To go to a frame identified by number 


1. 


During display, press F6 to overlay the Display Options menu. 


2. Move the highlight to Go to frame nn and press Enter. 
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Result: The analyzer opens an additional dialog box in which 
you can write the number of the frame you want. It won't let 
you ask for a frame whose number is larger than the number of 
frames in the buffer. 


3. Type the frame number and Press Enter. 


Result: The analyzer removes the overlaid dialog box and 
resumes display at the frame you requested. 


Search for Text 


One of the options available during display is to search through the 
capture buffer for a frame that contains a particular text. The text 
doesn’t have to be physically present in the frame. You can search for 
text that exists only in the analyzer’s interpretation of the frame. 


ON To search the capture buffer for a frame containing particular text 
O: } Pp SP 


1. During display, press F6 to overlay the Display Options menu. 


2. Move the highlight to Search for text (Figure 5-22). Don’t press 
Enter yet (you haven't yet told it what to search for). Move to 
the panel to the right. 


rSUMMARY—Delta T—DST: 
DISPLAY OPTION 


Display Go to frame nn 4 
Options Text = 
earch for patternd! 
Jump to mark dq In summary text 
Jump to trigger # In detail text 
In frame data 
Y Summary 
x Detail 
ore? 
Search summary lines or frame data for the specified text. 


se the arrow keys to move, or ENTER to do this function== 


3 Data 18 New 
display Menu capture 


Figure 5-22. Menu for requesting a text search. 


3. Move the highlight to Text =, and press Enter. 


ot 


Function Keys Available During Display 


Result: The analyzer opens a dialog box headed Enter text. 
Type up to 31 characters. The search is case sensitive. Press 
Enter to record the text you want to look for (Figure 5-23). 


4. Then tell the analyzer where to look—that is, whether to look 
in the Summary text, the Detail text, or the text of the frame 
data. Move the highlight to the line you want and press 
Spacebar to move the arrow of the radio control. 


— (When you choose Frame data as the place to look, you 
have the further choice of searching the text’s ASCII or 
EBCDIC representation.) 


5. Move the highlight back to search for text, and press Enter. 


Result: The Sniffer analyzer moves forward through the 
frames, searching for the text you entered. When it completes 
its search, it removes the overlaid dialog box and resumes 
display at the frame containing the target text. 


When you ask for a search in the Summary or Detail view, the search 
is not for characters in the frame itself, but for characters that appear 
in the analysis server's interpretation. The analysis server generates 
the Summary, Detail, or Hex display for each frame and searches it 
for characters that match your request. 


Figure 5-23 shows a request to search some LocalTalk frames for the 
phrase “Distance = 6” in the Detail view. 


SUMMARY—Delta T—DST———— 


Go to framenn @# 
Search for text ¢ 
Search fpENTER TEXT: 
Jump to 

Jump to Enter case-sensitive text to search for 


¥ Summary or press ESC to abort 


Y Detail 


Use TAB to select windows 


Figure 5-23. Dialog box to enter text to search for. 


The search starts with the frame following the one you are looking at 
and stops at the first match. If the search reaches the last frame in the 
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capture buffer without finding a match, searching continues from the 
first frame. If all frames have been searched without finding a match, 
the analysis server reports that and stops searching. 


KON To repeat a search for text 
1. Press F6 again (to return to the display options menu). 


2. Press S (for search for text). 


Result: The text you last searched for is still in the field marked 
Text =. 


3. If you're searching again for the same text, just press Enter. 
Otherwise, replace the search text and then press Enter. 


Search for Pattern 


You can search for a frame containing a particular pattern. Figure 5— 
24 shows the menu for specifying a search pattern. 


To search the capture buffer for a pattern 


1. Press F6 again (to return to the display options menu). 
2. Move the highlight to Search for Pattern (Figure 5-24). 
3. Move to the right to specify the pattern. 


pee ee T—DsT 
§.0059 FF RTMP R NET=1289 Routing entries= 


latch 
ont match 
x Either offset 


Go to framenn # AND Pattern = XXXX... 
Search for text # Offset = 200 
Search for patternd AND 
Jump to mark OR 
Jump to trigger # Pattern = XXXX... 
Offset = 020 
¥ Summary 


x Detail (POR Hexadecimal 
x Hex Match 4 Character 
ore! ore! 
Use this match? 
(Press Enter to change the name. ) 
Press space to select (/) or not select (x); Alt-space inverts all. 
21 = 8.0004 DC 267 CTS (Clear to send) 


cpt 
Help display Menus capture 


Figure 5-24. Specifying a pattern to search for. 


The procedure is exactly the same as the one for specifying a 
pattern in the capture filter (see page 2-19 ff). 


Ae 


Function Keys Available During Display 


4. After you've specified the pattern, return to Search for Pattern 
and press Enter. 


Result: The Sniffer analyzer moves forward through the 
frames, searching for the pattern you entered. When it 
completes its search, it removes the overlaid dialog box and 
resumes display at the frame containing the target text. 


As with text search, the search starts with the frame following the one 
you are looking at and stops at the first match. If the search reaches the 
last frame in the capture buffer without finding a match, searching 
continues from the first frame. If all frames have been searched 
without finding a match, the analysis server reports that and stops 
searching. 


When the Sniffer analyzer finds the pattern you requested, it displays 
the message 
Found at frame nn. 
If the Summary view is open, it highlights the frame. 
To repeat a search for pattern 
1. Press F6 again (to return to the display options menu) 


2. Move the highlight to Search for Pattern. 


Result: The pattern you last searched for is still there. 


3. If you’re searching again for the same pattern, just press Enter. 
Otherwise, revise the pattern, then return to Search for pattern 
and press Enter. 
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SUMMARY—Delta T—DST———sgk¢--———_—_—_______ 
9.0259 FF RTMP R NET=1289 Routing entries= 


atch 
Dont match 
x Either offset 


Go toframenn # Pattern = XXXX... 

Search for text #4 Offset = 020 

Search for patternd AND 

Jump to mark OR 

Jump to trigger OR Pattern = XXXX... 
Offset = 220 


Hexadecimal 
Character 


Use this match? 
(Press Enter to change the name.) 
=—Press space to select (/) or not select (x); Alt-space inverts all. 
21 = 8.6084 DC 267 CTS (Clear to send) 


: me 86 
Help displa Menu capture 


Figure 5-25. Specifying a pattern to search for. 


Forcing the Interpretation of an Embedded Protocol in 
an Unexpected Location 
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On occasion you may encounter frames that contain a known protocol 
embedded in such a way that the interpreters don’t recognize it. This 
may happen when two applications exchange data in a nonstandard 
way, or in a way that hasn’t yet become sufficiently standard for the 
protocol interpreter suites to know about it. 


When that happens, the analyzer may simply report that (in some 
lower-level protocol) it has found “xx bytes of data.” But you have 
reason to believe that, somewhere in that data field, there is an 
embedded protocol. Moreover, it’s a protocol that the analyzer could 
perfectly well interpret— if only it knew it was there. 


The Force Protocol feature gives you a way to tell the analyzer where 
to look for a protocol that it does not automatically recognize. Force 
Protocol works: 


* Only after you first enable the Force Protocol feature. 


* Only from within certain protocols that permit protocol 
forcing. 


* Only when, working from the Summary view, you identify 


Forcing the Interpretation of an Embedded Protocol in an Unexpected Location 


— The outer protocol (the one that contains an unexpected! 
embedded protocol) 


— The embedded protocol (and where it’s located) 
— Which frames should be interpreted this way. 


ON To force interpretation of an embedded protocol 
© 
1. Capture some frames that you believe contain a known 


embedded protocol in a location that the protocol interpreters 
don’t expect. 


In the Summary branch of the Display menu, enable protocol 
forcing. Move the highlight to Force Protocol and press 
Spacebar to toggle between xX (inactive) and / (active). 


Result: The analyzer enables a special use of the F3 key that 
operates only within a Summary display. (Usually, F3 starts 
display. Now, once display has started, you'll have a new 
temporary meaning of F3.) The special use of F3 is labelled 
Force Protocol. This meaning of F3 is in effect (and its label 
shows) when: 


— The Summary view is open and is the active view 
and 


— The highlighted line within the Summary view contains a 
protocol from which forcing is permitted. 


If you haven't yet started the display, press F3 to display 
frames in the capture buffer. To make use of Force Protocol, 
you must open the Summary view, and it’s generally useful to 
open Detail and Hex as well. 


Scroll until you find a frame that contains the embedded 
protocol. 


Depending on the circumstances, you may have various clues 
to identify the frame. You may be able to recognize some of its 
embedded data in the Hex view. You may recognize a 
particular socket as a destination in the Summary or the Detail 
view. The application may adopt a suggestive NetBIOS name 
as the destination of traffic containing the protocol. You may 
have to do some experimentation. 


1. Ofcourse, what is “unexpected” depends on point of view. You may expect the protocol 
to be just where it is. But the protocol interpreter suite you’re using doesn’t. 
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5. Inthe Summary view, place the highlight on the line with the 
protocol whose data field contains the embedded protocol. 
Provided the highlight is on a protocol from which forcing is 
possible, you'll see that F3 Force Protocl is visible atthe bottom of 
the screen (Figure 5-26). 


(Almost always, the highest level that the analyzer can 
interpret is the one that contains the unexpected protocol. From 
that point of view, it would be sufficient to use the Summary 
view with Highest level only. However, once you force an 
additional level of interpretation, you probably want to see 
both the new protocol and those that contain it. For this reason, 
it is usually preferable to deactivate Highest level only.) 


Delta T—DST————SRC 
Broadcast +IRMAuser 
IRMAuser = «SNA Gateway 
SNA Gateway «IRMAuser 
IRMAuser «SNA Gateway 
IRMAuser «SNA Gateway 

NA Gateway «IRMAuser 
SNA Gateway «IRMAuser 
IRMAuser = «SNA Gateway 
SNA Gateway «IRMAuser 
SNA Gateway «IRMAuser 
IRMAuser — «SNA Gateway 
IRMAuser —- «SNA Gateway 
SNA Gateway «IRMAuser 
SNA Gateway «IRMAuser 
IRMAuser = «SNA Gateway 
IRMAuser +SNA Gateway 
SNA Gateway «IRMAuser 


NET Find name Forte $GATEWAY3 
NET Name Forte $GATEWAY3 Recognized 
NET D=FFFF S=@3CA Session Initialize 
NET D=03CA S=FBFD Session ACK 

O3CA S=FBFD Data, 8 byte(s) 
NET D=FBFD S= i 
NET D=FBFD S=@3CA Session ACK 
NET D=@3CA S=FBFD Data, 8 byte(s) 
NET D=FBFD S=83CA Session ACK 
NET D=FBFD S=83CA Data, 37 byte(s) 
NET D=Q3CA S=FBFD Session ACK 
NET D=83CA S=FBFD Data, 24 byte(s) 
NET D=FBFD S=83CA Session ACK 
NET D=FBFD S=@3CA Data, 3 byte(s) 
NET D=83CA S=FBFD Session ACK 
NET D=@3CA S=FBFD Data, 5 byte(s) 
NET D=FBFD S=@3CA Session ACK 


IRMAuser «SNA Gateway NET D=@3CA S=FBFD Data, 5 byte(s) 
SNA Gateway «IRMAuser NET D=FBFD S=83CA Session ACK 
SNA Gateway +Novell@9Q6BD NET D=@6C9 S=1ADE Data, 3 byte(s) 


Frame 183 of 319 
3. Force} D 6Displygi/ Prev §8 Next 
Help § mark fprotocl Menus foptions™ frame § frame 


Figure 5-26. Summary view with F3 = Force Protocol enabled. 


10 New 
capture 


6. Press F3, Force Protocol. 


Result: The analyzer puts up the Force Protocol menu, 
temporarily overlaying the regular display (Figure 5-27). 
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SUTMARY—Delt. 
3. 6.9 


So 
m 


Offset = O01 
Force 
Protocol Force protocol <none> 


Resume default 


This frame 
This connection 
This address pair 
All frames 
orel 
Force the next level to be the protocol chosen in the right panel. 


U 
U 
U 
U 
U 
HE 
g 
8 
g 
8 
8 


se the arrow keys to move, or ENTER to do this function 
Frame 3 of 6 


Use TAB to select windows 
p= 3 Data al 18 New 
Help display Menus capture} 


Figure 5-27. Force Protocol menu overlaid on the Display view 


7. Describe the protocol you want the analyzer to use. 


a. Inthe panel to right, select the protocol you want the 
analyzer to use. 


Move the highlight to the one you want and press Spacebar. 
The list of alternatives includes all the protocols available 
through the set of protocol interpreter suites installed in 
this analyzer.! 


b. Set the offset at which the protocol starts. Move the 
highlight to Offset= and press Enter. The analyzer opens a 
dialog box in which you can enter the amount of the offset. 
When you've made your entry, press Enter to record it. 


The offset is the distance from the start of the data field in 
the outer protocol; that is, the distance from the end of the 
outer protocol’s header. (The outer protocol is the one you 
highlighted in the Summary view.) Write the offset in 
hexadecimal. 


8. Tell the analyzer which frames to interpret using the forced 
protocol. Move the highlight to the one you want and press 
Spacebar to select one of the choices. These are the four 
alternatives (also visible in Figure 5-27): 


1. Ifa protocol you want to use isn’t on the list, you can use the configuration utility to build 
an interpreter with the right combination; see Chapter 7. 


a 
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10. 


This frame The protocol will be forced for the 
currently highlighted frame, but not for 
any others. 


This connection The protocol will be forced for the 
currently highlighted frame, and for all 
frames earlier or later in the capture 
buffer that are part of the same 
connection or logical call. 


This address pair The protocol will be forced for all frames 
in the capture buffer passing in either 
direction between the DLC source and 
destination of the currently highlighted 
frame 


All frames The protocol will be forced for all frames 
now in the capture buffer. 


Apply the protocol you’ ve specified— or abandon it. 


To return to the display, with the protocol forced as you've 
specified, move the highlight to Force protocol and press Enter. 


To return to the display without forcing (but leaving the 
protocol and offset as you've selected), press Esc. 


Inspect the display for confirmation that you have forced the 
protocol interpretation correctly. 


Some confirming signs: 


— The forced protocol makes sense, revealing reasonable 
commands, addresses, and data. 


— Protocols within the previously-hidden protocol become 
visible and make sense. 


Some disconfirming signs: 


— The detail view of the forced protocol shows an invalid 
checksum (in a protocol that provides its own checksum). 


— The embedded protocol is shorter than the data field that 
contains it— not conclusive, but suspicious. 


— The embedded protocol is too short. The last line of the 
protocol’s Detail display will indicate when the interpreter 
reached the end of the data before the normal end for this 
protocol. 
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Undoing a Line of Forced Protocol 


Protocol forcing has a temporary effect on the display. If you close the 
display, or replace the contents of the capture buffer, the analyzer 
discards any protocol forcing you did earlier. When you save the 


capture buffer, the saved file does not contain any record of the 
protocol forcing you may have applied to it. 


While a display is active, the Force Protocol menu gives you a way to 
undo the forcing of individual frames. 
To undo a forced protocol 


1. Display the capture buffer using the Summary view with 
Highest level only turned off. (You can have other views open 
or not, as you wish.) 


2. Move the highlight to the line showing the outer protocol— 
that is, the protocol from which you forced interpretation. 


(For example, if you earlier highlighted NetBIOS and forced 
the interpretation of SNA, you should now highlight the 
NetBIOS line, not the SNA now visible below it.) 


3. Press F3, Force Protocol. 


Result: The analyzer overlays the Force Protocol menu. 


4. Move the highlight to Resume default, and press Enter. 


Result: The analyzer closes the Force protocol overlay and 
returns to the display. The interpretation of the highlighted line 
returns to its default. 


Forced Protocol Example: SNA Embedded within NetBIOS 


A personal computer on an Ethernet network uses an emulator that 
makes it appear as a 327x terminal to the 3274 controller on an IBM 
mainframe. The PC’s emulator card uses Novell NetBIOS over XNS. 
Once it has set up a NetBIOS connection to the controller, the terminal 
emulator embeds SNA commands in IRMA protocol, and transmits 
these as the data field of a NetBIOS packet. The interpreter knows 
how to recognize SNA within an IRMA packet, but it doesn’t know 
how to tell that a NetBIOS packet will contain IRMA. The presence of 
an IRMA packet is a convention of the two ends of the connection. 
There is no header that announces “The rest of this field is IRMA 
data.” 


To decode the encapsulated IRMA and SNA data, you might proceed 
as follows: 


= 
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1. Capture frames from the PC using the terminal emulator. 
Enable Force Protocol. Display the captured frames with the 
standard protocol interpreters, including Novell XNS and 
NetBIOS. 


The display shows NetBIOS transmission between the PC and 
the SNA gateway, but doesn’t decode them (Figure 5-28). 


Sve eat Server “Chris F Enet"; Fli for list, Fi2 for menus 
446 IRMAuser SNA Gateway DLC 882.3 si 

XNS NetWare NetBIOS 

O3CA S=FBFD Data, 8 byte(s 
ateway + DLC 842.3 size=48 b 

XNS NetWare NetBIOS 

NET D=FBFD S=@3CA Session ACK 

185 8167 SNA Gateway «IRMAuser DLC 882.3 size=48 bytes 
XNS NetWare NetBIOS 


NET D=FBFD S=@3CA Session ACK 
fs ain 189 of 319 


_.2 .... = Not End Of Message 
Dies 


N 
No Resend Needed 


: Datastream Type = 6 (Session Data) 
: Source Connection ID = FBFD 

: Destination Connection ID = 83CA 

: Send Sequence = 9999 

: ACK Sequence = 9001 

: (8 byte(s) of data] 


Frame 183 of 319 
AB to select windows 


Use T. 
i 2 Set (§3 Force—4 Zoom fb 6Displygi/ Prev #8 Next 10 New 
Help § mark @protocl™ in Menus foptions™ frame § frame capture} 


Figure 5-28. Uninterpreted NetBIOS data from a terminal emulator. 


2. Identify a frame that probably contains SNA data. (In this case, 
there are two clues. First, the PC establishes a connection with 
a NetBIOS address named “Forte Gateway”. Second, by 
forcing EBCDIC rather than ASCII display in the Hex view, 
some SNA messages are apparent in the NetBIOS data field. 


3. With the highlight on the line produced by the NetBIOS 
interpreter (labelled “NET” in the left margin), press F3 Force 
Protocol.! 


4. Inthe Force Protocol menu, select IRMA protocol at offset 0, 
and apply it to this frame only. (You could select SNA at offset 
3, and thereby jump over the three bytes of IRMA.) If that 
seems to work, you can then select This connection, since the 
protocol probably applies throughout this NetBIOS 
connection. 


1. The summary of the preceding line says “NetWare NetBIOS.” That's the interpretation of 
the NetWare frame saying that “NetBIOS follows”, and not the NetBIOS frame itself. 


ca 
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The result is visible in Figure 5-29. The IRMA protocol becomes 
visible as a result of forcing, and the SNA appears automatically since 
it is embedded in the IRMA frame ina standard manner. 


BA2. ze=92 bytes 
XNS NetWare hetBI0e" 
NET D=@3CA S=FBFD Data, 43 byte( 
IRMA S = 80253 Server Data Messa 
SNA C FMD user data 
Frame 202 of 319 


SNA FMD-RU (Function Management Data) 


SNA: [32 bytes of FMD character-coded data] 


Frame 282 of 319 


EX 
9028 88 OB O8 02 B0 BH 1B 89 22 2E B4 55 40 B6 FD FB 
9038 CA 83 £4 00 2B OB BO 8 2B BD 04 OO OO OD 04 FD 


0048 00 2C BO 16 OO OO 02 03 80 OOK 
iy FO F1 FO 40 60 40 E2 E3 C8 49 E5 E3 C1 D4 40 C9 M1 
Misi E2 40.Ci C3 E3 C9 F505 15 40 

Frame 282 of 319 


Use Pe to select ee 
i 2 Set 4 Zoom 6Displyu—i7 Prev —8 Next 10 New 
Help § mark in _ loptions™ frame § frame capture 


Figure 5-29. Forced protocol reveals IRMA and SNA within NetBIOS. 


Exporting a Report on Frames in the Capture Buffer 


You can generate a report on the frames in the capture buffer. The 
report can be sent directly to the printer, or to a file. The file can be 
formatted for printing or for input to another program (for example, 
to a spread sheet). 


Frames that pass your current display filters are included in the 
report. The fields reported are those currently displayed on the 
screen. However, since the report isn’t confined by the size of a screen 
panel, it doesn’t exactly duplicate the layout you’d see on screen. For 
example, reports do not attempt to represent colors or highlighting. 


Range of Frames Included in the Report 


The report includes all displayable frames within a certain range. By 
default, the Sniffer analyzer assumes the range includes all 
displayable frames, from the first to the last. 


ol 
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Y Summary | From first frame 
Cable Tester ¢# | x Detail From frame 3 4d 
Traffic Generator 4] x Hex 

Capture filters x Two viewports | To last frame 
Trigger To frame 54 

Capture Filters 

Display 2 eae < Device LPT1 

Files anage names Device LPT2 

Options File 

Exit 


x Delimited format 
/ Print page titles 
Page size = 58 


Print the capture data to a device or file 
using the currently selected display formats. 
se the arrow keys to move around in the menu’ 


3 Data i 
display capture! 


Figure 5-30. Options for printing to device or file. 


Alternatively, you can limit the range by setting the frame numbers of 
the first and last frames to be printed. A pair of radio controls flips 
between First or Last and a specific number. 


The Sniffer analyzer initializes the display with its guess about the 
frame numbers you might want. It assumes that (if you choose 
something other than first to last) you’d want frames lying between 
the marked frame and the current frame (Figure 5-30). (You mark a 
frame by pressing F2 while it is highlighted; if you haven't set the 
mark, the mark is on frame 1. The current frame is the one now 
highlighted in the display.) 


To change the printing range, highlight the phrase From frame or To 
frame and press Enter. The analyzer opens a dialog box for you to 
supply a frame number. 


Where the Output Goes: Printer or File 
You have three possible destinations for the printer output: 
LPT1 A printer directly attached to the Sniffer server’s LPT1. 


LPT2 A printer directly attached to the SniffMaster console from 
which you are operating the server. (The console may then 
redirect the output to a file on its own hard disk, if it has 
been configured to do so.) For a discussion of console 
configurations, see Distributed Sniffer System: Installation and 
Operations Manual. 


File A file that you name on the Sniffer server's hard disk. 
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For more details of the physical setup of attached printers, see 
Distributed Sniffer System: Installation and Operations Manual. 


Figure 5-31 shows a printed report from an Ethernet network. This 
report shows part of the first page of a report on the Summary view 
in two-station format.! 


Sniffer Network Analyzer data from 21-Mar-91 at 13:33:00, unsaved capture data, Page 1 


SUMMARY Delta T From NwkGn1080A44 From NwkGn1080AC8 


M 1 DLC 802.3 size=560 bytes 
XNS NetWare NetBIOS 
NET D=E573 S=3924 Data, 512 byte(s) 
NGCP Screen data for row 1 col 1 
2 0.0016 DLC 802.3 size=48 bytes 
XNS NetWare NetBIOS 
NET D=3924 S=E573 Session ACK 
3 0.0021 DLC 802.3 size=490 bytes 
XNS NetWare NetBIOS 
NET D=E573 S=3924 Data, 441 byte(s) 
4 0.0015 DLC 802.3 size=48 bytes 
XNS NetWare NetBIOS 
NET D=3924 S=E573 Session ACK 
10 0.5266 DLC 802.3 size=282 bytes 
XNS NetWare NetBIOS 
NET D=E573 S=3924 Data, 234 byte(s) 
NGCP Screen data for row 2 col l 
1d 0.0012 DLC 802.3 size=48 bytes 
XNS NetWare NetBIOS 
NET D=3924 S=E573 Session ACK 
15 0.5473 DLC 802.3 size=176 bytes 
XNS NetWare NetBIOS 
NET D=E573 S=3924 Data, 127 byte(s) 
NGCP Screen data for row 1 col 80 
16 0.0010 DLC 802.3 size=48 bytes 
XNS NetWare NetBIOS 
NET D=3924 S=E573 Session ACK 


Figure 5-31. Portion of printed report of a Summary view. 


Print to File 


You can direct the printed output to a file on the Sniffer server’s hard 
disk. (If you subsequently want to transfer the file from the server to 
the console, use the file transfer utility, described in Distributed Sniffer 
System: Installation and Operations Manual.) 


1. The example shows part of the control exchange between a Sniffer analysis server and a 
SniffMaster console, using NGCP protocol. 
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Content of the Exported Files 


In general, a report sent to the printer or to a file contains the same 
information you see on the screen, but without the restriction of the 
small panel. Detail sent to a file is treated differently from Detail on 
screen. On screen, only a small amount of Detail is visible, but you can 
scroll to any level. In an exported file, scrolling is not an issue. 
However, ina file, Detail includes only the protocols you request. See 
Figure 5-32. 


Displayed on screen Sent to file or printer 
Summary shows a line for each protocol selected in the protocol or 
address level filters. 


When a frame’s Summary is 

highlighted in the upper panel, 
its Detail is visible in the lower 
panel. 


A frame’s entire Summary 
appears first, and then its Detail. 


A frame’s Detail starts with the 
level that is highlighted in the 
Summary view. You can scroll to 
see the interpretation of any 
protocol the frame contains, 
regardless of display filters. 


Detail is limited to the protocols 
selected in the Protocols filter. 


Detail follows the Summary for 
each frame, with protocols in 
order from lowest to highest. 


Figure 5-32. Treatment of Summary and Detail on screen and to a file. 


Delimited Format for Export to a Spread Sheet 


5-54 


When you select Delimited format, the output is written as comma- 
separated values. In this format, each character field is surrounded by 
double quotes. A numeric field is written as ASCII characters without 
quotes. Successive fields are separated by commas. 
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SUMMARY—Delta T—-DST—————SRC 

128 = 5.4869 15625.255 715625. 22 DLC LAP type=DDP Short 
DDP D=15625.255 S=15625.228 Type 
RTMP R NET=1289 Routing entries=- 

123. 1.8765 1645.20 21289. 123 DLC LAP type=DDP Long 
DDP D=1845.28 S=1289.183 Type=3 
ATP C [D=2671 LEN=8 
Lo C OpenSess WSS= — Version=9} 

=DD 


Up ong 
ODP D=1289 183 S=1045.28 Type=3 
ATP R ID=2671 LEN=@ NS=2 
ASP R OpenSess SSS=139 ID=49 ERR 
$0828 1845.20 21289. 193 DLC LAP type=DDP Long 
DDP D=1845.28 S=1289.183 Type=3 
ATP D ID=2671 
$0233 1045.28 21289 103 DLC LAP type=DDP Long 
DDP D=1845.28 S=1289.183 Type=3 
ATP C ID=2672 LEN=0 
ASP C Tickle ID=49 
0.0031 1289.193 1045.28 DLC LAP type=DDP Long 
DDP D=1289.183 S=1845.28 Type=3 


1 2 Set 6Displug’ Prevails Next 10 New 
Help mark Smmoptionss frameim™ frame capture’ 


Figure 5-33. Portion of a Summary display on screen. Compare with CSV 
format of the same data in Figure 5-34. 


Comma-separated values is a format widely used for importing data 
to spread sheets. The file’s first line defines the fields. Each 
subsequent line is a record, containing the value of each field. A line of 
the exported file corresponds to a row of the Summary view on 
screen. That is, the file has either one line per frame or one line per 
protocol level. 


When you turn off highest level only, a frame’s display may take 
several rows. On screen, a field that is the same for every row (for 
example, the frame number) is written only once, on the first of the 
frame’s rows. That field is left blank in the frame’s later rows. 
However, in the comma-separated values file, every row is filled in, 
even when a field repeats the row above. Figure 5-33 and Figure 5-34 
show screen and CSV versions of the same data. 
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“Frame”, 
5.4869, ' 
5.4869, 
5.4869, 
1.8765, 
1.8765, 
1.8765, 
1.8765, 
8.2222, 
9.8222, 
$8222, 
$8222, 
6.2028, 
6.9828, 
6.8828, 
9.0633, 
9.2033, 
6 2033, 
$8033, 
6.2631, 
6.0631, 
6.0031, 
9.8031, 
8.8044," 
6.8044," 
8.0044, 
6 6044, 
6.0044, 
6.2662," 
6.2662," 
6.2662, 
§.2662, 
§.2662, 
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6.2035, 
§. 6035, 
9.2035, 
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Figure 5-34. A CSV file created with all levels of the Summary display. 


(It isn’t illegal to ask for CSV format while reporting Detail or Hex 
views. However, the output is in CSV format only for the Summary 
view. The CSV file includes data from the other views, but in the 
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standard printer format.) 


If you check the page titles option, each page (whether written to a file 
or directly to the printer) starts with a heading. The heading specifies 
the date and time the data was recorded. It also shows the name of the 
network (when the file was captured live) or the name of the file 
(when the capture buffer was loaded from a saved file). At the far 


"LAP type=DDP Long” 


D=1845.28 S=1289.183 Type=3 (CATP)" 


"C ID=2671 LEN=8" 

"C OpenSess WSS=253 Version=0120" 

" LAP type=DDP Long” 

"D=1289 183 S=1845.28 Type=3 CATP)" 
."R ID=2671 LEN=@ NS=8 “ 

"R OpenSess SSS=139 1D=49 ERR=2" 


LAP type=DDP Long” 


"D=1645, 28 S=1289.183 Type=3 CATP)" 
"D [D=2671 " 


LAP type=DDP Long" 
D=1845.28 S=1289.183 Type=3 (CATP)" 
C ID=2672 LEN=0" 
C Tickle ID=49" 

LAP type=DDP Long” 


"D=1289 1983 S=1845.28 Type=3 (ATP)” 
"C [D=16531 LEN=8" 
"C Tickle ID=49”" 


LAP type=DDP Long” 


“D=1845.28 S=1289.183 Type=3 (ATP)” 
","C 1D=2673 LEN=46" 

"."C Command ID=49 SEQ=@ LEN=46" 

,"C Login AFPVersion 1.1" 

." LAP type=DDP Long” 

""D=1289 183 S=1845.28 Type=3 (ATP) 
"\"R 1D=2673 LEN=@ NS=@ (Last)" 

sigan 
FP". 


R Command RESULT=-5819 LEN=8" 


“R Error=ParamErr ” 
,” LAP type=DDP Long” 
"| "D=1845 26 S= 1289, 103 Type=3 (ATP)" 
"\"D 1D=2673 ° 
,” LAP type=DDP Long" 
"| "D=1845. 28 S=1289.183 Type=3 CATP)" 
"\"C 1D=2674 LEN=8" 
,"C CloseSess ID=49" 
" LAP type=DDP Long” 

, D=1289 183 S=1845 20 Type= 3 (ATP)" 
"\"R [D=2674 LEN=@ NS=8 " 
"'"R CloseSess “ 


right, it shows the page number. 


Page Size 


Exporting a Report on Frames in the Capture Buffer 


There are two blank lines between the heading and the start of the 
data. 


Having page titles also causes explicit page breaks. When you select 
page titles, the Sniffer analyzer includes a form feed character after the 
last non-blank line of each page. 


Selecting CSV format turns off page titles. (You can turn them on 
again if you really want; however, most applications that accept CSV 
format won’t want page titles.) 


When you select page titles, you can also set page size, the number of 
lines per page. By default, the number is 50. That is the total number 
of printed lines. For example, if you use headings, and accept the 
default of 50 lines per page you get the heading, two blank lines, and 
47 lines of data. 


Since each page break is indicated by an explicit form feed, there is no 
separate setting for the physical length of the paper. 


To send a report to file or printer 


1. Set Display filters to exclude extraneous frames (page 5-5). 
These may include 
¢ Address level filter 
¢ Destination class filter 
e Station address filters 
* Protocol filters 
¢ Pattern match filters 


2. Set Address level filters (page 5-7) to determine how source 
and destination will be identified in the output. The output will 
show each frame’s source and destination at the highest of the 
levels you checked. (Notice that Address level affects the way 
source and destination are described even when it doesn’t alter 
which frames are displayed.) 


3. Open the views (Summary, Detail or Hex) that you want 
included in the report (page 5-14). 


4. Activate or deactivate Highest level only, as appropriate (page 


5-17). 

5. Activate or deactivate Two-station format, as appropriate 
(page 5-18). 

6. Set the width of the source and destination name fields (page 
5-17). 
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10. 


11. 


12. 


The default width is 12, the minimum 8. Making these fields 
wider or narrower displaces the fields to the right by a 
corresponding amount. The analyzer does not fold the output 
lines (so the treatment of long lines is up to the printer or 
application that processes the output). 


Set the range of frames to be printed: 
* First frame 
* Last frame 


To change the numeric frame number, move the highlight to 
First frame or Last frame and press Enter. The analyzer opens 
a dialog box to receive a new number. Type the number you 
want and press Enter. 


Set the output destination: 

* LPT1 (the server's printer) 

* LPT2 (the console’s printer) 

* File (on the server's hard disk) 


If you ask for output to file, when you finally move the 
highlight to Print and press Enter, the analyzer will prompt 
you to name the output file. 


Indicate whether you want the Summary fields to be written in 
delimited format (page 5-54). 


Indicate whether you want titles at the top of each page (page 


5-56). 


Titles, if used, gives the date and time that data were collected, 
the name of the file from which data was loaded (if any), and 
the page number, in one line. You can’t have page titles for 
output to file in delimited format. 


Set the total number of printed lines on each page. 


The title line, if any, precedes the page’s data, and is separated 
from the data by two blank lines. Data lines are thus reduced 
by 3 when you have titles. Each page of data is terminated by a 
formfeed (hex 0C). 


The default number of lines is 50. The maximum is 9999. If you 
set 0 lines, output is not broken into pages and there is no 
trailing formfeed. 


When you've completed all the specifications (except the 
filename when you requested output to file) move the 
highlight to Print and press Enter. 


What happens next depends on the destination: 


LPT1 The server starts printing to the device attached to its 
parallel port. (If the device isn’t ready, the server will — 
after a delay— report that fact.) 


Network 
General 


Managing Names in the Displays 


LPT2 The server starts transmitting the data back to the 
console, which redirects it to the console’s parallel port. 


File The analyzer opens a dialog box for you to write the 
file’s name. Initially, the dialog box contains the path 
but no name. (To change the default path, or to create a 
new directory, see page 6-9.) 


The path shows C (the server's hard drive) and the 
current directory. You can overwrite the directory if 
you wish. Write your filename using no more than eight 
characters. Don’t include an extension; the Sniffer 
analyzer automatically attaches the extension .PRN for 
a printer file, or .CSV (“comma-separated values”) fora 
file in the delimited format. If the name you propose is 
already in use, the analyzer warns you; you can abort 
the request or go ahead and overwrite the existing file. 


Managing Names in the Displays 


To make its displays more readable, the Sniffer analyzer permits you 
to substitute names for numeric addresses. The menus offer several 
options to supply new names, modify existing names, or preserve the 
use of names. 


The Working Name Table 


To translate between the addresses and the names that appear in the 
display, both the monitor and the analyzer refer to a name table. For 
each address, the name table contains three columns (see Figure 6-7 
and Figure 6-8, page 6-15 ff): 


Address level The protocol in which the address can occur. The 
list of possible address levels depends on the 
protocol interpreter suites you have installed. 


Station address The sequence of bytes that constitute the numeric 
station address. 


Symbolic name The word or phrase you have assigned to the 
address (blank, when you haven’t assigned one). 


In the table, a station address never exists alone, but is always paired 
with a specific protocol. A symbolic name is thus an equivalent, not 
for an address alone, but for a particular pairing of protocol-and- 
address. 


Dynamic Nature of the Name Table 


A working name table contains two kinds of entries: 
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* Named protocol-and-address pairs. 


* Unnamed protocol-and-address pairs (whose name field is 
therefore blank). 


The Sniffer analyzer sorts the table alphabetically by name. The 
unnamed addresses, having blank names, appear first. 


The working name table is built and used in a sequence of stages: 
1. Initialization 


Capture 


2. 

3. First display 
4. Individual frame display 
5 


Editing (may be done at any time) 


Initialization 


When it starts, the Sniffer analyzer initializes its working name table 
with names and addresses in the file STARTUP.xxD. (It omits 
addresses that lack names in the startup file.) The Sniffer analyzer also 
inserts its own address and assigns itself the name This Sniffer. (It 
does so even when the saved table previously assigned it a different 
name.) 


There is a maximum size for the working name table. It has room for 
500 names. 


Capture 


During capture, when you show pairwise or individual traffic counts, 
the Sniffer analyzer attaches a label to each counter. The label shows 
the station’s address. When the name table already contains a name 
for that address, the analyzer uses the name rather than the numeric 
station address. 


First display 


The first time you use Display after a new capture, the Sniffer 
analyzer scans all the frames in the buffer for new addresses. It puts 
new addresses into the working name table with blank names (see 
page 5-65). 


Display of individual frames 


During display, each time the analysis server generates an entry for 
the Summary or Detail description of a frame, it checks whether the 
frame’s addresses are in the name table. It adds any address it finds 
up to the limit of 50 unnamed addresses at each address level. 


Managing Names in the Displays 


Editing 
Before or after any of these stages, you can edit the working name 


table. You can add new addresses, insert names for addresses, or edit 
any of the entries. 


Three Ways to Assign Names to Addresses 


You manage names by editing the working name table. There are 
several different routes: 


Edit You can manually provide the symbolic name by 
editing the working name table (see page 5-62). 


Resolve Name Ask the Sniffer analyzer to search a previously- 
saved name file and to copy from it symbolic 
names for addresses that are unnamed in the 
working name table (see page 5-66). 


Look for names Certain protocols let stations exchange tables of 
names and addresses. When you ask the Sniffer 
analyzer to Look for names, it scans the capture 
buffer for such messages and extracts names 
from them (see page 5-65). 


Saving the Name Table for Later Use 


Editing the Name Table 


When you ask the Sniffer analyzer to Save names, it copies the current 
working name table to the startup file stored on its hard disk. Then 
each time you restart the analyzer, the working name table is primed 
with the names in the startup file. 


When the startup file contains names that are no longer appropriate, 
you can edit them individually or clear them all out and start over; see 
the section that follows. 


The changes you make affect the working name table (in the analysis 
server's main memory). When you exit the analysis server, it discards 
the working name table. (If you haven’t saved the name table, the 
analyzer warns you that it’s about to discard it. If you want to save the 
name table, first cancel the request to exit.) To record the names, 
before you exit, use the Save names command to copy the working 
table into the startup file. 


The procedure to edit the name table is simple. However, the task gets 
even easier when you let the analyzer compile a list of addresses for 
you before you start editing. 
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Q 


Xx 


Ly 


To edit the working name table 


1. 


EDIT AE $$$ Level 
DLC 


Before you open the name table, get the analyzer to compile a 
list of addresses that occur in your traffic. To do that: 


a. Capture some traffic (live from the network or by replaying 
a saved file). Press F10 to stop capture. 


b. Move the highlight to Display, then to Filters, then to 
Address level. Set the address level filters to activate all 
levels for which you want addresses 


c. Return the highlight to Display and press Enter. (Or press 
F3.) Display some of the captured frames. 


— If you’re only interested in DLC addresses, it is 
sufficient to the display the first frame. The act of 
opening the display causes the analyzer to scan the 
entire capture buffer for DLC addresses). 


— If you’re interested in higher level addresses, scroll 
through the capture buffer. The analyzer adds higher 
level addresses to the name table as it displays them. 


Press F6 for Display options. Scroll down to Manage names. 
(You can also get there by F5, then Display, then Manage 
names.). With the highlight on Manage names, press Enter. 


Result: the Sniffer analyzer opens a dialog box showing the 
current name table (Figure 5-35). One line in the table is 
highlighted. You can scroll through the table to move the 
highlight or bring other names into view. 


‘Addres: 


<New station> 

<New station> IP 
DLC §287018827C@ 
DLC §2608C836367 


IP (36.53.8.195] 
All Campus IP (36.255. 255.255] 
Cerberus IP (36.53.0.18] 
Swanee IP [36.56 .0. 2081] 
Backbone A DLC 620701 002BA\ 
Backbone B DLC 920781002C69 
Broadcast DLC FFFFFFFFFFFF 
ClearView IP (36.54.8.12] 
Fido DLC AAGGO301131B 
Konig DLC 62698C036318 
Tarpit IP (36.8.8.47] 
Lundy IP (36.54.9.11] 


IP (36.53.8.42] 
se 4 and tT then press ENTER, or ESC to return. 


pda 


Figure 5-35. Dialog box to edit the working name table. 


Managing Names in the Displays 


Each name consists of a pairing of level (that is, protocol) and 
address. For example, in Figure 5-35, the name Fido is attached 
to a station of level DLC and address AA0003 01131B. The 
name Tarpit is attached to a station of type IP and address 
[36.8.0.47]. 


3. To edit a name, move the highlight to the type-and-address 
pair you want to change, and press Enter. 


Result: The Sniffer analyzer opens a dialog box to receive anew 
name (Figure 5-36). 


EDIT NAME 


Enter a new name for IP address [36.56.9.208] 


Press DEL to delete this station. 
Press ESC to leave it unchanged. 


Press ESC to abort: 


Figure 5-36. Dialog box to give a station a new name. 


4. Toadd an address that is nowhere on the list, scroll to the top 
of the list to one of the lines marked <new station>. Each <new 
station> line is qualified by its level. There’s always a line for 
the DLC level. In addition, there’s a <new station> line for each 
level checked in the address level filter. Highlight the 
appropriate line and press Enter. 


Result: the Sniffer analyzer asks for an address and a name 
(Figure 5-37).! 


EDIT NAME 


Enter the new IP address of the station 
in the format [n.n.n.n], where each n < 256 


(11.22.33.44] 


Enter the name of the new station: 


BIG TREE eee 


Press ESC to abort: 


Figure 5-37. Dialog box to type a new station’s name and address. 


1. Although an IP address is always displayed with square brackets around it, during input, 
the analyzer accepts an address without brackets. 


5-63 


Distributed Sniffer System: Analyzer Operations Manual 


5. To prevent an address from being discarded, assign it a name. 
The name needn't be its final name. But an address whose 
name field is left blank is treated as an “unknown station” 
during capture, and is discarded from the name table when the 
table is rebuilt (at Save names, or when the analyzer is started). 


When you specify a name for a station that already had a name, your 
new name thereby replaces the former name. Within the name table, 
addresses must be unique. However, names don’t have to be unique; 
it’s permissible to assign the same name to different addresses. 


When you use the Edit Names dialog box, the Sniffer analyzer revises 
the name list in working memory. It doesn’t update the stored file of 
names, so the revision is temporary. If you want to make the change 
permanent, you have to Save names (described next). 


To save the current working name table so that it will be 
automatically effective next time you run the analyzer or monitor 


In the main menu, select Display, then Manage names, and 
finally Save names. Press Enter. 


Result: The analyzer copies all named addresses from the 
current working name table to the file 
c:\xxSNIFF\STARTUP.xaD. 


Effect on the Sniffer Monitor’s Name Table 


The Sniffer analyzer and the Sniffer monitor make reference to the 
same name file. Like the analyzer, the monitor uses a working name 
table. When you start the monitor, it initializes its working name table 
with DLC addresses and their accompanying names copied from the 
saved names file STARTUP.xxD. The monitor ignores higher-level 
addresses. Thus, when you execute Save names, any changes in the 
names or DLC-level addresses will also affect subsequent uses of the 
monitor. Similarly, when the monitor saves names or addresses, those 
changes are merged into the file STARTUP.xxD and affect DLC-level 
names and addresses in the analyzer’s subsequent displays. 


Clearing the Name Table 


5-64 


vy 


The option Clear all names empties the Sniffer analyzer’s working 
name table, removing both names and addresses. Use this command 
when you want to start over, perhaps before resolving names from a 
name file or looking for embedded names within higher-level 
protocols in the capture buffer. 


Clear all names followed by Save names would empty not only the 
Sniffer analyzer’s working name table but also the name table in the 
startup file. 


General 


Managing Names in the Displays 


Scanning the Capture Buffer for Addresses 


The first time you display captured frames following a new capture, 
the analysis server scans the entire capture buffer for addresses. 
During the scan, it notes all addresses at any of the levels checked in 
the address level filter. When it finds a new address, it adds it to the 
working name table. 


The name table has a maximum size. It has room for 500 addresses. 
During its scan for new addresses, the analysis server stops adding 
addresses when the table is full. Also, it never adds more than 50 
addresses at any level, even when there’s room for them 


When the buffer contains many frames, the search may take a few 
seconds; the analysis server displays a thermometer-style gauge 
showing percentage completion. 


Each address thus added has a blank name field. The analysis server 
sorts the address in alphabetical order by name. That puts the entries 
with blank names at the top of the list. When you edit names, it’s easy 
to see where additional names are needed. 


Taking Advantage of the Automatic Address Scan 


‘a 


When you expect to assign names to new high-level addresses, set the 
address level filter before you first display. That way the analysis 
server will automatically add up to 50 new addresses at each level; 
you have only to name them. 


However, if you start display without setting the address level filters, 
you can still get the analysis server to add new addresses to the table. 
Press F6 for display options, go to address level, and check the levels 
you want. Press F3 to return to display. As you browse through the 
captured frames, whenever the Sniffer analyzer displays a frame, it 
adds any new addresses at the levels currently marked with a /. This 
doesn’t scan the entire capture buffer, but it does add addresses from 
the frames you display. 


Addresses you haven’t named are temporary. When you execute 
Save names, the analyzer purges addresses that remain unnamed. So 
if you want to keep a record of new addresses, assign each a name — 
any name— before you execute Save names. 


Looking for Names within the Captured Frames 


Certain protocols (for example, Novell NetBIOS, or TCP DNS) let 
stations exchange tables of addresses and the names their users have 
adopted. When you ask the Sniffer analyzer to Look for names, it 
scans the capture buffer for such messages. From them, it copies two 
kinds of entries to the working name table: 
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* Names for addresses already in the name table without names, 
* Bothname and address for addresses not yet in the table. 


This technique may find names or addresses for stations that weren't 
themselves sending or receiving. 


LN To look for names within the frames in the capture buffer 

Ro 

1. Capture some frames, live from the network or by replay from 
a file. 


2. Press F3, Display. 


3. Press F6, Display options. Move the highlight to Manage 
names and then to Look for names. Press Enter. 


Result: The analyzer scans the entire capture buffer for 
protocols that exchange name information, and adds new 
addresses and their names to the working name table. (It does 
not revise names for addresses that were already in the table.) 


The analyzer reports the number of address-and-name pairs it 
added to the working name table. 


7 Names found this way may be quite transitory. For example, you may 
find a name that a user assigned for a single work session. The user 
may move to another machine and assign the name to a different 

address. Because such names are so readily changed, you may not 
want to save aname table constructed this way; it may be wrong next 
time you use it. 


Resolve Names by Referring to Other Name Files 


To help identify unnamed addresses, you may have the Sniffer 
analyzer look up names from an external file. The file from which 
names are taken is in the same format as STARTUP.xxD. Presumably 
it exists because at some earlier time you copied and renamed the 
version of STARTUP.xxD that was then current, or downloaded it to 
the server from the console. 


KO To resolve unnamed stations by searching an external file 
KX 


1. Capture some frames, live from the network or by replay from 
a file. (The procedure won't run if there’s nothing in the 
capture buffer.) 


2. Move the highlight to Display filters, then Address level. Put 
a check mark at each level you want included in the search. 


3. Move the highlight to Display, then Manage Names, then 
Resolve Names. Press Enter. (It doesn’t matter whether you 
first display the capture buffer.) 


Be 


Managing Names in the Displays 


4. Press F6, Display options. Move the highlight to Manage 
names and then to Look for names. Press Enter. 


Result: The Sniffer analyzer opens a dialog box showing a list 
of files that it recognizes as name files. Move the highlight to 
the one you want and press Enter. 


The analyzer scans the entire capture buffer for addresses at the 
DLC level and at any higher levels you checked in the Address 
level filter. The analyzer amends the working name table by 
adding to it the address and level of any station represented in 
the capture buffer but not named in the name file. That gives it 
a pooled list of unnamed stations, including unnamed stations 
that it just found in the capture buffer and any that were in the 
name table but unnamed. 


For each address in its list of unnamed stations, it searches the 
external file. Wherever it finds a name for one of its unnamed 
addresses, it inserts the name in the name table. 


When the analyzer has completed its search, it displays a 
message telling you how many unnamed addresses were in the 
working name table, and how many of them it was able to 
name. 


5. Topreserve the names you have added, execute Save names to 
copy the working name table into the startup file. This saves 
addresses that have names, but discards addresses that still 
lack names. 


Importing a Name File 


You can upload files from the SniffMaster console to the server. That 
gives you a way to install name files that you acquired from 
elsewhere, or that you constructed with a text editor. Once you have 
the additional name files, the Resolve names command can search 
them for names to go with the as-yet-unnamed addresses in the 
server's working name table. 


For the analyzer to recognize and use a name file, the file’s name must 
have an identifying extension and its text must be in a standard 
format. The name file’s name and format are described in Chapter 6, 
see pages 6-10 and 6-14. 


For the procedure to upload a file from console to server, consult 
Distributed Sniffer System: Installation and Operations Manual. 


Total Size of the Name Table 


The Sniffer analyzer sets a limit on the size of the name table. The 
overall limit is 500 entries. 
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There’s an additional limit of 50 names at each address level each time 
you start a new display or each time you run Resolve names. 


Files of Saved Frames 


The Sniffer analyzer permits you to save all or part of the contents of 
the capture buffer to a file. Or, you can load the capture buffer with 
frames from a previously-saved file. By loading previously-saved 
frames, you can examine frames captured at another time or place, or 
frames sent to you for study. 


Loading a File of Previously-Saved Frames 


You can load the capture buffer directly from a previously saved file, 
without going through capture. 


Fon 
ey 


To load the capture buffer with a file of saved frames 


1. 


In the main menu, move the highlight to Files, then Load, and 
then Data, and press Enter. 


Result: The Sniffer analyzer opens a dialog box containing a list 
of previously-saved capture files and directories. The list is in 
alphabetical order. A capture file has an extension that starts 
with a two-letter code for the network (EN for Ethernet, TR for 
token ring, SY for synchronous WAN). The third letter is C (for 
capture). The analyzer only shows you filenames whose 
extensions indicate that they’re from the network for which 
your server is configured. 


To change to a different directory, move the highlight to one of 
the rows labeled <DIR>. 


The notation .. <DIR> in the top row indicates the directory 
one step nearer the root. Other entries with <DIR> are 
subdirectories. To see the list of files in a subdirectory, 
highlight its name and press Enter. 


Move the highlight to the file you want. Alternatively, to jump 
directly to a part of the list, type a letter from the keyboard. The 
highlight moves to the next entry starting with that letter. 


When you've highlighted the name of the file you want, press 
Enter to load it. 


4. Press F3 to display the capture buffer. 


Files of Saved Frames 


Saving a File of Frames 


While you have frames in the capture buffer (either because you just 
captured them, or because you loaded them froma file), you can save 
the frames in the buffer to a file. You can save: 


* Everything in the capture buffer, or 
* Only those frames that pass your current display filter; or 


* Only frames within a particular range. 


® To save frames in the capture buffer to a file 


1. While displaying the capture buffer, if you wish to save only 
those frames that pass the display filters, set the filters 
appropriately (see “Setting the Display Filters” on page 5-5ff). 


2. Press F5 to return to the main menu. Move the highlight to 
Files, then Save, then Data. Don’t press Enter yet. 


From first frame 
From frame 12 < 


Load 

Save ig last frame 
Change path 4 

Delete datafile ¢ 
Make directory /# x Filtered only 


To frame 28 


Save capture-buffer data to a disk file. 


se the arrow keys to move, or ENTER to do this function 


il 3. Data 10 New 
Help display capture 


Figure 5-38. Menu to save captured frames to a file. 


3. Set the range of frames to be saved: 
* First frame 
* Last frame 


To change the frame number, move the highlight to it and press 
Enter. The analyzer opens a dialog box to receive a new 
number. Type the number you want and press Enter. (It’s the 
same procedure as setting the range of frames to be printed; see 
“To send a report to file or printer” on page 5-57). 
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4. Indicate whether you want to save all frames or just those that 
pass the current filters. Highlight Filtered only and press 
Spacebar to toggle between J (active) and x (inactive). 


5. When you've completed the specification (except the filename) 
move the highlight back to Data and press Enter. 


Result: The analyzer opens a dialog box for you to write aname 
for the file to be created. Initially, the dialog box contains the 
path but no name. (To change the default path, or to create a 
new directory, see page 6-9.) 


The path shows C (the server's hard drive) and the current 
directory. You can backspace over that part of the display and 
write the name of a different directory if you wish. 


Write your filename using no more than eight characters. Don’t 
include an extension; the Sniffer analyzer automatically 
attaches the extension .xxC (where xx is the two-letter network 
code, EN for Ethernet, TR for token ring, or SY for WAN/ 
synchronous). If the name you propose is already in use, the 
analyzer warns you; you can abort the request or go ahead and 
overwrite the existing file. 


Deleting a File of Saved Frames 


Saved Setups 
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The Files menu also offers you the option to delete a file of saved 
frames. When you highlight Delete and press Enter, the analyzer 
opens a dialog box showing the names of files of saved frames, in 
much the same way as it shows a list of files you could load or replay 
(see “To capture froma file” on page 2-50). The list includes only 
capture files related to the network you are now using. 


Pressing Enter while the name of a file is highlighted indicates that 
you want to delete it. The Sniffer analyzer opens a dialog box headed 
Warning with the message 

Deleting: xxxxxxx 
where xxxxxxx is the name of the file. 


You can press Enter to go ahead and delete the file, or Esc to return to 
the list of data files without deleting it. 


Your “setup” is the particular constellation of display options, filters 
and controls you’re using. You can save the setup to a file. Later, you 
can load that file, thereby restoring all those options to the values they 
had when you saved the setup. 


(coxa) 


Saved Setups 


KD To save your current setup 
KOZ 1. Check that the way things are now is the way you want them 


Contents of a Setup File 


to be restored. (See the next section for a listing of what's 
included in a setup and what's not.) 


In the main menu, move the highlight to Files, then Save, then 
Setup. Press Enter. 


Result: The analyzer opens a dialog box for you to write the 
file’s name. Initially, the dialog box contains the path but no 
name. (To change the default path, or to create a new directory, 
see page 6-9.) 


The path shows C (the server's hard drive) and the current 
path. You can backspace over that part of the display and write 
the name of a different directory if you wish. Write your file 
name using no more than eight characters. Don’t include an 
extension; the Sniffer analyzer automatically attaches the 
extension .xxS (where xx is the two-letter network 
abbreviation). If the name you propose is already in use, the 
analyzer warns you; you can abort the request or go ahead and 
overwrite the existing file. 


The setup file records every option that you can set by a check mark 
or a radio control. Some items set in other ways are also included, but 
some are not. 


Included in a setup file 


General options (for example, WAN/synchronous encoding, 
token ring remove-if-no-signal). 


Capture options (for example, whether to display skylines or 
meters, whether to show individual or pairwise counts). 


Capture filters (including source and destination addresses, 
and pattern match logic together with the individual patterns 
and their offsets). 


Trigger options (including options for stopping capture and 
pattern match logic together with the individual patterns and 
their offsets). 


Display options (including views and levels). 


Display filters (including source and destination addresses, 
and pattern match logic together with the individual patterns 
and their offsets). 
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* Printer options (including whether to send output to a printer 
or to a file, and whether to include headings and page 
numbers). 


Not included in a setup file 


* The path you may have set for locating the directory of files to 
be loaded or saved. However, you can record that with the Set 
path command. 


* The capture buffer. However, you can save that by the 
command sequence Save and then Data. 


* The name table. However, you can save the current working 
name table by the command sequence Manage names and then 
Save names. 


Your setup may refer to addresses (for example, in a station 
address filter). When you display the filter, you may see the 
station’s symbolic name rather than its numeric address. 
However, the saved filter really contains the numeric address. 
The symbolic name is regenerated during display by looking 
for that address in whatever version of the name table is then 
current. 


Using a Saved Setup File 


5-72 


When you first start the Sniffer analyzer, it checks for the existence of 
a file called STARTUP.xxS. If it finds such a file, it treats it as a setup 
file and loads it automatically. Otherwise, it uses the Sniffer analyzer’s 
standard defaults. 


KAY To activate a saved setup manually 


1. Inthe main menu, move the highlight to Files, then Load, then 
Setup, and press Enter. 


Result: The Sniffer analyzer opens a dialog box showing you a 
list of saved setup files. Move the highlight to the one you want 
and press Enter. 


The analyzer loads the setup file. There is no specific message 
saying it has done so. It resets all options the way the setup file 
specifies. 


f KON To restore Network General's default options 


1. Follow the procedure for loading a saved option file. When the 
analyzer prompts you for the file’s name, select the file called 
c:\ CAPTURE\DEFAULT.xxs. 


DISTRIBUTED SNIFFER SYSTEM™ 


CHAPTER SIX: THE ANALYSIS SERVER'S USE OF FILES a) 


General 


Chapter 6. The Analysis Server’s Use of Files 


Chapter Overview 


File Names 


This chapter describes: 


* Files that the Sniffer analysis server uses and the directories 
that contain them. 


* The internal format of files used to store name tables, setups, 
and saved traces. 


During everyday use of the Sniffer analysis server, you should have 
little or no need for the information in this chapter. However, 
knowledge of the file organization may prove useful when you 
import files from somewhere else or export files produced by the 
analyzer for analysis elsewhere. This chapter presumes that you're 
familiar with the naming and storage conventions of the DOS file 
system. 


Under the DOS operating system, a file’s name is composed of two 
parts. The two parts are separated by a dot. The first part (sometimes 
called the base name) may contain up to eight characters. The second 
part (called the extension) consists of three letters. (Omitting the dot 
and the letters that follow it has the same effect as writing a dot and 
three blanks.)Chapter 6, “Chapter Figure 6-1The Analysis Server's 
Use of Files.” 


Certain extensions have special significance to DOS. For example, an 
executable file has the extension .EXE, .COM or .BAT; DOS won’t 
execute a file whose name has some other extension. Figure 6-1 shows 
some of the extensions that occur in files used by the Sniffer analysis 
server. The first two of these are standard DOS conventions, while the 
others are more specific. 


69 


Distributed Sniffer System: Analyzer Operations Manual 


Extension File type 


Executable file. The extension may be omitted from 
the DOS command that invokes its execution. 


Batch file (an executable file consisting of commands 
in the DOS shell language). The extension may be 
omitted from the DOS command that invokes its 

execution. 


Output file generated by a report generator for 
printing (whether or not sent directly to a printer). 


Output as “comma-separated values,” intended as 
input to a spread sheet. 


Script used to generate the selection menu; used by 
the executable file MENUX.EXE. 


Menu script to generate a particular analysis entry in 
the selection menu. 


Configuration script describing the protocol 
interpreter suites for a network. 


Help file to explain choices in the Sniffer analyzer’s 
menus. 


Figure 6-1, Extensions in Sniffer file names. 


Each of the analyzer’s executable files refers to files that are specific to 
a single network. Each of these files has a name whose extension 
classifies it by use and by network. The first two letters of the 
extension indicate the network, and the last letter indicates the type of 
file. For example, if you’re working on Ethernet and save the capture 
buffer to a file called MYDATA, the analyzer gives it the extension 
.ENC (Ethernet captured frames). Letters used in extensions are listed 
in Figure 6-2. 


6-4 


File Names 


First Two Letters 


foken Ring 
WAN/ Synchronous. 


Last Letter 
eS 


Figure 6—2. Letters used in the extension of an analyzer file’s name. 


Names for the Sniffer Analyzer’s Executable Files 


You don’t ordinarily see the name of the executable files that in fact 
provide the Sniffer analyzer’s services. That's because, to start work, 
you move the highlight to an entry in the selection menu; you don’t 
invoke the file by typing its name. An item in the menu describes a set 
of services (for example “Token Ring Analyzer”) but doesn’t show 
you the name by which DOS identifies the underlying executable file. 
For each service listed in the menu, there’s a separate executable file. 
Each executable file for a Sniffer analyzer has a name that encodes the 
network and the protocol interpreter suites it provides. The name is 
constructed as follows: 


The first two letters indicate the network, as shown in Figure Figure 
6-2. Those two letters are always followed by the letters SN. 


The next four positions are used to encode the protocol interpreter 
suites that are linked into the executable file. This encoding uses any 
of the 32 characters 0-9 or A-V. This base-32 encoding permits any 
combination of protocol suites to be given a unique name. For 
example, analysis for Ethernet with interpreter suites for DECnet, 
TCP/IP and ISO has the names ENSN2000.EXE. Analysis for token 
ring with the same suites and also the IBM protocol suite has the name 
TRSNIOO0.EXE. 
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Directories 


Figure 6-3 summarizes the principal directories on the Sniffer 
analysis server's hard disk (drive C). 


ROOT 


AUTOEXEC. BAT 
CONFIG.SYS 


DOS Operating system 


Used for Server-to-Congole transport 


NETBEUI or WINTCP or IPXEN or IPXTR 
Used 
Used by Analyzer configuration utility by 
TOOLS 
oc2°..[iure the 
Server 
Used by selection menu and config. utility 
CONFIG 
RRORIEE ¢ Monitor executable file 
e Analyzer executable files 
¢ Setup files 
¢ Startup (name) files 
Used 
HELP ¢ Monitor help 
¢ Analyzer help by both 
Analyzer 
NEWPI = Used by Analyzer 
configuration utility and 
Monitor 
CAPTURE 
* Trace files (captured frames) 
* Output files (PRN and CSY) 
Used 
xxHIST only 
by 
Monitor 


XXREPORT 


Figure 6-3. Directories on the Sniffer analysis server's hard disk. 


a 


Directories 


DOS Directory 


CONFIG Directory 


Menu files 


Configuration Files 


The root directory contains the files AUTOEXEC.BAT and 
CONFIG.SYS. The server refers to them automatically each time you 
reboot the server or restart it following a power-down. 


The Sniffer analysis server's AUTOEXEC file establishes the path: that 
is, the list of directories in which the operating system searches for 
executable files. The AUTOEXEC file invokes the selection menu. 
From there, you select one of the Sniffer analysis server’s major 
functions (Monitor, Analyzer, File Transfer, and so on). 


The DOS directory contains files belonging to the operating system 
(except that a few DOS files that are in the root directory). The path 
includes the DOS directory, so the operating system looks there to 
find its own files. Normally, you won’t need to make any changes to 
files in the DOS directory. 


The CONFIG directory contains scripts that generate the Sniffer 
analysis server's selection menu, the analyzer’s main menu, the 
monitor’s main menu, and the menu used by the configuration utility. 


Each executable file is accompanied by a menu file whose name is the 
same but has the extension .MNU rather than .EXE. The executable 
files reside in the xxSNIFF directory (that is, ENSNIFF, TRSNIFF, or 
SYSNIFF). However, all .MNU files reside in the \CONFIG directory. 
For example, the executable file TRSNIO00.EXE (in the directory 
\TRSNIFF) is accompanied by the menu file TRSNIO00.MNU (in the 
\CONFIG directory). 


The server uses the various menu files to generate entries in the main 
selection menu. Each menu file is responsible for the menu entry 
corresponding to one analyzer or monitor. The .EXE files and the 
-MNU files are already supplied by Network General. When the 
configuration utility (described in the next chapter) generates a new 
executable file, it automatically generates the corresponding .MNU 
file as well. Similarly, when the utility deletes an executable file, it also 
deletes the corresponding .MNU file. 


The configuration files list the facilities available to Sniffer analyzers 
on the particular server. Its name is formed from the two-letter 
network abbreviation, the letters SNIFF, and the extension .CFG (for 
example, for Ethernet, ENSNIFF.CFG). The .CFG file lists all the 
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Tools Directory 


XxSNIFF Directory 


Capture Directory 


protocol interpreter suites that can be installed in an Ethernet 
analyzer. When you use the Configuration Utility to build an analyzer 
with a new combination of protocol interpreter suites, the menu you 
see (listing the available interpreter suites) is governed by information 
in the configuration files. 


The TOOLS directory contains the program that generates the Sniffer 
selection menu, and various other utilities that go with it. The Sniffer 
server's DOS path directs the operating system to the \TOOLS 
directory, so you won't usually need to make any explicit reference to 
it. 


The \TOOLS directory has a subdirectory QC2. It contains the 
Microsoft Quick-C compiler, and its subdirectories LIB and BIN. The 
configuration utility makes use of these, but you never have to deal 
with them explicitly. 


One directory contains the principal executable files, both for the 
monitor and for the various analyzer configurations. The directory’s 
name is formed from the two-letter network abbreviation followed by 
the letters SNIFF. For example, for token ring, the directory is called 
TRSNIFF; for Ethernet it’s ENSNIFF; and for WAN/Synchronous, it’s 
SYSNIFF. A server has whichever of these directories is appropriate, 
but not more than one of them.! 


The \CAPTURE directory is where the Sniffer analyzer ordinarily 
saves files of captured frames. It’s also the default destination for 
output files such as .PRN files of .CSV files. 


Creating Alternate Directories for Saved Files 


6-8 


To keep various sets of captured data separate (for example, data 
collected at different times or under different circumstances), you 
may want to set up additional directories to contain the files. The 
batch file that starts the Sniffer analysis server makes \CAPTURE the 
current directory. 


1. A self contained portable Sniffer onelyer may be equipped for more than one network, in 


which case it has more than one such directory. 


Directories 


JX To create a new directory 
KOA 1. Inthe main menu, move the highlight to Files, then to Make 


directory, and press Enter. 


Result: The analyzer opens a dialog box to receive the name of 
the new directory. The analyzer supplies the current path. If 
the path hasn’t been changed, it is C:\CAPTURE\. 


2. Write your new name to the right of the final \. That will make 
your new directory a subdirectory of \CAPTURE. 
Alternatively, you can backspace into all or part of the name 
the analyzer suggested, and replace it with whatever you 
prefer. To record the name and create the directory, press 
Enter. 


« The analyzer limits the name to alphabetic characters, so you can’t 
specify an extension for a directory created in this way. The operating 

system does not accept more than 8 characters in the main part of a 
name. If you write a longer name, the analyzer truncates it to the first 
8 characters. The Sniffer analyzer accepts the path you specify. It 
doesn’t verify that your path is syntactically valid or that the directory 
actually exists. If the path is not valid, when you subsequently try to 
read or write a file, you will get the error message Invalid path. 


Setting the Path to a Directory for Saved Files 


Whenever the analyzer opens a dialog box in which you select an 
existing file for input or name a file for output, it starts by showing 
you the path to its current directory. Initially, the path is 


C:\CAPTURE\ 
Oe 


iy 


To specify the initial path to saved files 


1. From the main menu, move the highlight to Files, then to 
Change path, and press Enter. 


Result: The analyzer opens a dialog box in which you can edit 
the path in accordance with your wishes. 


2. Write the path you want. The path should end in \. To record 
your preference, press Enter. 


Result: Whenever it opens a dialog box for you to specify a file 
to read or write, the analyzer will start from the path you 
recorded here. 


m The analyzer accepts the path you specify. It doesn’t verify that your 
path is syntactically valid or that the directory actually exists. If the 
path is not valid, when you subsequently try to read or write a file, 
you will get the error message Invalid path. 
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Names for Files of Captured Frames 


A data file created by saving frames from the capture buffer is called 
a capture file (or sometimes a trace file). It has the same internal format 
as the capture buffer. You cannot read a capture file as text. 


When you create a data file, assign it any name you wish in eight 
letters or fewer. The Sniffer analyzer automatically supplies the 
name’s extension (the three letters following the dot). The extension 
consists of the two-letter network code followed by the letter C for 
“capture.” The codes are shown in Figure 6-4. 


Ethernet 


Token Ring 
WAN/ Synchronous 


‘igure 6—4. Extensions in the names of capture files. 


Storage of Setups and Name Tables 


For information about names or setups, the Sniffer analyzer refers to 
three kinds of files. Each type has a characteristic extension. As 
described in Figure 6-2 (page 6-5), the extension consists of the two- 
letter network abbreviation (EN for Ethernet, SY for synchronous, TR 
for token ring) and a final letter to indicate the type of file. Each time 
the Sniffer analyzer starts execution, it refers to one or more of these. 
The types of files are listed in Figure 6-5. 


Contains How Used 


Symbolic names | Each time you start the analyzer, it builds its working name 
for addresses. table by reading names from \xxSNIFF\STARTUP.xaD. 


STARTUP.xxD 


You may edit the working name table (Manage names then 
Edit names) and save the revision (Manage name then 
Save names). 


STARTUP.xxI | Symbolicnames | Each time you start the analyzer, it reads the table of 
formanufacturer | manufacturer IDs from \xxSNIFF\STARTUP.xal. 
ID codes 


STARTUP.xxS 
or 
(after startup) 


ANYNAME.XxS 


Values of user- 
settable options 
in the analyzer 
menus. 


None is required and none is initially provided. 


If you have saved a setup file and given it the name 
\xxSNIFF\STARTUP.xxS, the analyzer automatically 
loads it at startup. (Other setup files are usually saved in 
and loaded from the \CAPTURE directory.) 


Figure 6-5. Files referred to at startup. 


ot 


Storage of Setups and Name Tables 


Each time you start a Sniffer analyzer, the software automatically 
checks for the presence of the startup files it needs. It looks for them 
in the \xxSNIFF directory. If it finds them, it uses them to set its 
working name table, or to initialize the analyzer’s filters and settings. 
If the analyzer doesn’t find a file it needs, it uses a default setup or an 
empty name table. 


Saving Setups and Names to a File 


The three types of files (name files, manufacturer ID files, and setup 
files) have different mechanisms for loading and saving. These 
mechanisms are summarized in the paragraphs that follow and in 
Figure 6-6. In the figure, a gray arrow indicates automatic loading 
each time the analyzer is started. A black arrow indicates a file that 
you can load or save upon command. 


Sniffer Software 


WORKING COPIES 


Automatic 
loading 
at 
initialization 


ot, Co 
oe eo 


| STARTUP. xxI | § 


STARTUP. xxD 


—\xxSNIFF directory 


Figure 6-6. Stored files and working copies of name tables and setups. 
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Modifying the Default Setup 


The Sniffer analyzer does not require a file called STARTUP.xxS. 
When the analyzer starts, it checks to see whether such a file exists. If 
it exists, the analyzer uses it. If it doesn’t exist, the analyzer uses its 
own list of default settings for options. 


PON To alter the setup with which the analyzer starts 
This is a variant of “To save your current setup” on page 5-71. 


1. A saved setup is a snapshot of the analyzer’s current settings. 
You should start by making sure that your current settings are 
the ones you would like to have the analyzer supply 
automatically at startup. (For a listing of what’s included ina 
setup and what's not, see “Contents of a Setup File” on page 5— 
Pll 


2. Inthe main menu, move the highlight to Files, then Save, then 
Setup. Press Enter. 


Result: The analyzer opens a dialog box for you to write the 
file’s name. Initially, the dialog box contains the path but no 
name. 


Overwrite whatever is now in the dialog box. Replace it by 
C:\ENSNIFF\STARTUP (for Ethernet) 
C:\TRSNIFF\STARTUP (for token ring) 
C:\SYSNIFF\STARTUP (for WAN/synchronous) 

Don’t include an extension; the Sniffer analyzer automatically 

attaches the extension .xxS (where xx is the two-letter network 

abbreviation). If the file already exists, the analyzer warns you; 
you can abort the request or go ahead and overwrite the 
existing file. 


Restoring the Setup to Network General’s Defaults 


Suppose you have been using a customized setup and wish to revert 
to the default setup with which Network General shipped the Sniffer 
analysis server. You can do that in either of two ways, one lasting and 
the other temporary. 

KN To make a lasting return to Network General's default setup 

X< 


1. From the analyzer’s main menu, highlight Exit and press Enter 


2. Inthe server's selection menu, highlight Exit to the operating 
system and press Enter. 


3. Atthe DOS prompt, type the command to rename the file now 
called \xxSNIFF\STARTUP.xxS. 


oa 


Name Tables 


FON 
RY 


Storage of Setups and Name Tables 


Choose a new name that preserves the extension .xxS but 
changes STARTUP to anything else. The DOS command is 
RENAME STARTUP.xxS ANYTHING. * 


Result: Each time you start the analyzer thereafter, it will find 
no file called STARTUP.xx S, and so it will use its standard 
defaults. 


4. To return to the Sniffer server's selection menu, type 
menu 
and press Enter. 


To make a temporary return to Network General's default setup 


1. From the analyzer’s main menu, move the highlight to Files, 
then Load, then Setup and press Enter. 


Result: The analyzer opens a dialog box in which you may 
choose the name of a setup file to load. 


2. Choose the setup file called \CAPTURE\DEFAULTS.xxS and 
press Enter. 


Result: The file contains a duplicate of the analyzer’s default 
settings. When you load this file, it restores the default setup. 
This will not affect the initial setup the next time you start the 
analyzer. 


Procedures for assigning names to stations are described in Chapter 5, 
starting at page page 5-62. This section describes the format of files 
that contain name tables. 


While it runs, the Sniffer analyzer uses an internal directory called the 
working name table. Each time you start the analyzer thereafter, it 
initializes the working name table by reading from a file. Ordinarily, 
the file it reads is \xxSNIFF\STARTUP.xxD. 


If the analyzer can’t find \xxSNIFF\STARTUP.xxD, it looks in the 
current directory (that is, the directory identified by the Change path 
command). The batch file that starts the server normally makes 
\CAPTURE the default directory, so the analyzer looks next for 
\CAPTURE\STARTUP.xxD. 


If it doesn’t find that file either, the analyzer sets up an empty name 
table, containing only the address of the server’s own monitoring card 
and the name “This Sniffer.” 


You may have additional reference files of names and station 
addresses. These are either renamed copies of what was once a 
STARTUP.xxD file, or files in the same format created by an editor 
and downloaded to the server. When you create such a file, the name 
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Building Name Files 


6-14 


you give it must be something other than STARTUP, but must have 
the same extension as a startup file. 


You can have the analyzer consult these additional name files by 
executing the Resolve names command (page 5-66). 


In all cases, the extra name files are used as a source of names to fill 
blanks in the working name table. There is no command to load an 
entire substitute name file the way you loada setup. 


A name file is identified by an extension consisting of the two-letter 
network code followed by the letter D. There are two principal ways 
to generate a name file: by saving and then renaming the working 
name table, and by writing a name file from scratch with a text editor 
and then transferring it to the server. 


To build a name file from the current working name table 


1. From the analyzer’s main menu, move the highlight to 
Display, then Manage names, then Edit names, and press 
Enter. 


Result: The analyzer opensa scrollable dialog box in which you 
can edit the name table. 


2. Put the information you want into the working name table (see 
“To edit the working name table” on page 5-62). When you've 
finished adjusting the table, press Esc to return to the menus. 


3. Move the highlight to Save names and press Enter. The 
analyzer saves a file called \xxSNIFF\STARTUP.xxD. It 
contains names and address for all stations that had been 
named in the working name table, but omits stations to which 
you had not assigned names. 


4. Exit from the Sniffer analyzer. At the server’s selection menu, 
highlight Return to the operating system and press Enter. 


5. At the DOS prompt, copy and rename the file STARTUP. xxD. Put 
the new copy into a convenient place (for example, the 
\CAPTURE directory). Give ita name that isnot STARTUP but 
has the same extension, by a command such as 

COPY \xxSNIFF\STARTUP.xxD \CAPTURE\newname .* 


I. If you wish to maintain several independent name files, use DOS commands to give them 
arbitrary names. Before you start the analyzer, (a) assign anew name to your existing file 
STARTUP.xxD, and then (b) copy the one you wish to make active, giving the copy the 
name STARTUP.xxD. 


Storage of Setups and Name Tables 


Writing Your Own Name File 


Alternatively, you can build your own name files directly. This 
section describes a name file’s internal format. 


All name files have the same format, which applies both to the file 
called STARTUP.xxD and any other name files you may use as 
sources. Figure 6-7 shows part of a name file. Since a name file is a 
standard ASCII file, you can built it at the console or any other PC 
using any standard text editor. 


station "Broadcast" 
station "Error Log” 
station "ipSi” 
station "ipS2" 
station "ipS3" 


addrtype “DLC” CQQQFFFFFFFF 
addrtype “DLC” C2g200202008 
addrtype “IP” (36.19.8.13] 
addrtype “IP” [36.11.8.14] 
addrtype “IP” (36.11.9.23] 
station "ipS4” addrtype “IP” (36.2.9.5) 
station “ipS5" = addrtype “IP” [36.22.9. 28] 
station “Long, 31-Character Station Name” = addrtype “DLC” 490022000202 
station “Mary” = addrtype “DLC” 16925A2033BF 
station "This Sniffer” = addrtype “DLC” 482004000001 
station “Tom” = addrtype “DLC” 10@05A@02FEB 
station "Faquard” = addrtype "“XNS" {8@QGAC7CEFE 


0 6 ok ot 


Figure 6-7. Sample name file. 


For convenience during subsequent display, the Save names 
command sorts the rows of the table alphabetically by name. 
However, the analyzer does not require a name file to be in 
alphabetical order. 


The following features of a name table are illustrated in Figure 6-7 
and Figure 6-8. 


Type 

Each line starts with a word or symbol that identifies its type. The 
three types are distinguished by the following as their first non-blank 
characters: 


station The balance of the line describes one station’s name and 
address. 


addrtype The balance of the line sets the default address type 
(protocol) that applies to subsequent lines that don’t 
include it explicitly. 


/* A line that starts with /* and ends with*/ isa comment and 
is not executed. 


Name 


The station’s name to the right of the word station. The name must be 
enclosed in double quotes. 
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Address type 


Each address must be assigned to a specific type (that is, protocol). 
The type can be stated in either of two ways: 


* Explicitly for each address, by including the phrase 
addrtype “DLC” 
to the left of the address (as shown in Figure 6-7). A name file 
generated by the Save names command is entirely in this form. 


- Implicitly, using the current default type (Figure 6-8).An 
address that has no explicit type is presumed to belong to the 
current default type. The default type is initially “DLC”. The 
default type is set by each use of addrtype, and remains in 
effect until another addrtype. 


Address 


There is an = sign between the name and the address. An address is 
not enclosed in quotes. Each address is written in a form appropriate 
to its type (the same way the Sniffer analyzer displays it in the detail 
view). For example, a 6-byte DLC address is written as 12 
hexadecimal digits. A 4-byte IP address is written as four decimal 
numbers separated by dots and entirely surrounded by square 
brackets. 


Name Table with Default Types 


Figure 6-8 shows the same information as Figure 6-7, but makes use 
of default types. To improve readability, the file may contain 
redundant blanks or blank lines, as well as comments. A comment 
starts with /* and continues to */. 


station "Error Log" = C#0200000028 
addrtype “IP” 


station “ipSi" = [36.18.8.13] 
station “ipS2" = (36.11.9.14] 
station “ipS3" = [36.141.8.23] 
station "ipS4" = [36.2.9.5] 

station "ipS5" = [36.22.8.28] 


station “ipS6" = [36.26.8.54] 

station "ipS7" = [36.26.9.56] 

addrtype "DLC" 

/* Long name inserted as a test */ 

station “Long, 31-Character Station Name"=490920000202 
station “Mary” = 19095A@033BF 

station “This Sniffer" = 48000A002001 

station "Tom" = 1@@05A8@2FEB 

addrtype "XNS" 

station "Faquard” = 88QQQAC7CEFE 


Figure 6-8. The name file of Figure 6-7 rewritten with default types. 


Alphabetization of Station Names 


The order of entries in a name file doesn’t matter. 


oc 


Storage of Setups and Name Tables 


When the Sniffer analyzer builds and displays its working name table, 
it shows the list in alphabetical order by name. Addresses that you 
haven’t named (and therefore have blank names) appear at the top of 
the list. 


Each time you edit the working name table, the Sniffer analyzer re- 
alphabetizes the list. When you execute Save names, the saved file 
preserves the order of the working name table (but discards entries 
that aren’t named). 


Table of Manufacturer ID Codes and Abbreviations 


On most LANs, an address consists of six bytes. The first three 
represent the manufacturer. The analyzer attempts to represent the 
first three bytes by a six-character abbreviation of the manufacturer’ s 
name. The address then appears as six characters of manufacturer 
abbreviation followed by six characters of hexadecimal, for example 
Intr1n031EF7. 


The table of manufacturer codes and names is located in the file 
startup.xxI, where xx is the two-letter code for the network, and I 
indicates the ID table. The file’s internal format is illustrated in Figure 
6-9. The figure shows the content of the file STARTUP.xxI for a 
network that transmits least-significant-bit first (for example, 
Ethernet but not token ring). The comments in the file are for the 
convenience of human readers and have no effect on the analyzer’s 
use of the file. (For compactness, the lower part of the table is shown 
here with three entries per line. In the file, each entry has a line of its 
own.) 
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/* Sniffer table of assigned manufacturer IDs. ef 
/* 

/* This is for networks where the LSB is sent first, such as sh 
/* Ethernet, StarLAN, and PC Network. Note that we've put in here */ 
/* what we actually see in the real world, not what IEEE would like 
/* 

manuf "VisTec" = 800022 /* Visual Technology, Inc. */ 
manuf "NwkGnl" = 620065 /* Network General Corp. */ 
manuf "Prteon" = 220093 /* Proteon (bit-reversed from token ring!) */ 
manuf “Amrstr” = @@@09f /* Ameristar Technology ay 
manuf "Wl1flt" = Q020a2 /* Wellfleet ¥/ 
manuf “NCD " = @@00a7 /* Network Computing Devices, Inc. */ 
manuf "NSC" = @2@@a9 /* Network Systems Corp. #/ 
manuf "RND " = Q@@0b@/ /* RAD Network Devices Ltd. */ 
manuf “Cimlin" = 000@b3 /* CIMlinc ¥/ 
manuf “WstDig" = @2@0cH /* Western Digital */ 
manuf "HP EON" = @00%c6 /* H-P Intlgnt Networks Oper (EON) */ 
manuf "IBM" = 10005a /* (not bit-reversed from token ring) */ 
manuf “Intrln" = 820701 /* Interlan, Inc. #/ 
manuf "NSC" = 980017 /* Network System Corp. m7. 
manuf “Intrgr” = 280036 /* Intergraph */ 
manuf “Univtn" = @82049 /* Univation wf 
manuf "IBM" = 08@05a /* (bit-reversed from token ring) */ 


manuf "“ComDes" = 082067 /* ComDesign */ 


manuf "Xerox " = 00fGaa manuf “CMC " = @2cfif "DEC " = 802b 
manuf “Dove " = Q02Qb7 manuf “Bridge” = 280202 "Mtaphr" = 280026 
manuf "MIPS " = Q006b manuf “ACC " = 280203 “Spider” = 80239 
manuf “Ardent” = 00207a manuf “Symblx" = 680905 "DCA" = 080041 
manuf "Cayman" = 220289 manuf “Apple " = 080007 "Sequnt" = 280247 
manuf "TRW " = 90202a manuf “BBN” = 280028 "Encore" = 8804c 
manuf “Cisco " = Q820c manuf “H-P " = 280029 "BICC " = 88004e 
manuf “NeXT " = 00002f manuf “Nestar” = 0820a "Ridge “ = 980068 
manuf “Sytek " = 000018 manuf “Unisys” = 88082b “SilGrf" = 080069 
manuf "Novell" = 220@1b manuf “AT&T “ = 980018 “AT&T " = 28006a 
manuf “Altos " = 2028c8 manuf “Tktrnx” = 080011 “Exceln" = 2802606 
manuf “Gould " = 2@@@dd manuf “Exceln” = 980014 "Vtalnk" = 8807c 
manuf "Acer " = 02Ge2 manuf "DG" = 280P1a "Xyplex" = 082087 
manuf “Alantc” = Q00ef manuf "DG" = 8@01b "Kinetx" = 80289 
manuf “Agilis" = 00805c manuf “Apollo” = 28@@1e "Pyramd” = 88028b 
manuf "Intel " = QGaakd manuf “Sun “ = 980020 “Xyvisn" = 08008d 
manuf “U-B" = Q&dd0d manuf “NBI “ = 880022 “Retix " = 080092 
manuf "U-B " = Q&dd#i manuf “CDC “ = 880925 "DEC * aaQ003 
manuf "3Com " = 22608c manuf “TI " = 980828 "DECnet" = aafea4 


Figure 6-9. Manufacturer ID translation. 


Manufacturer IDs in the table are shown as they appear in the 
computer once they have been captured. The IEEE assignment of IDs 
specifies the sequence in which bits are transmitted on the wire. For 
networks that transmit each byte low-order-bit first (such as Ethernet) 
the address you see after it has been captured is the byte-by-byte 
reverse of what was transmitted on the wire. For example, the code 
used by IBM, is transmitted on the network by the sequence 00010000 
00000000 01011010. It appears to a token ring analysis server as 

10 00 5A, but to an Ethernet server as 08 00 5A. See the discussion of 
the bit-reverse option in Chapter 5, page 5-27. 


Data Exported to Printer or to File 


Data Exported to Printer or to File 


The contents of the capture buffer (before or after filtering) may be 
sent to a file on the server or to a printer attached to the server or the 
console. If sent to a file, the contents may be in a printer format (with 
or without page titles and page numbers), or in the CSV format 
recognized by standard spread sheets. (For details of this procedure, 
see Chapter 5, “Exporting a Report on Frames in the Capture Buffer” 
on page 5-51 ff.) 


The files thus produced have the extension .PRN for printer files and 
-CSV for spread sheet files. 


Format of Saved Data Files 


For some purposes of data analysis, you may want to upload data to 
the console for further analysis. After you've transferred data to a 
local computer, you can (for example) write a program that reads 
through a file of saved frames. The easiest format to work with is the 
ASCII file you get when you “print” the capture buffer to a file. 
Especially if you choose the option to omit page titles, the resulting 
file may contain the information you want in an easily-accessible 
format. 


Alternatively, you may prefer to operate directly on the trace file that 
the Sniffer analyzer writes in response to the Save data command. 
This section describes the format of such a trace file. 


Each trace file consists of sequences of variable length binary records. 
Since all 256 byte values are possible within the data, you cannot edit 
this file using an ordinary text editor. 


The first 16 bytes of a trace file contain a text message identifying the 
file as one containing data collected by the Sniffer analyzer.! The 
message is followed by an end-of-file character (hex 1A, also called 
Ctrl-Z). Even if you accidentally type the file to the screen, or 
otherwise treat it as a text file, the display reaches a terminator before 
reaching unprintable characters. 


Structures within the Data File 


Following the text message string, the file contains an arbitrary 
number of variable-length records. Each record has a type, identified 
in its first two bytes. The three principal types are: 


* Version record 


¢ Frame record 


1. For historical reasons, the message in all such files is “TRSNIFF data”, regardless of the 
network on which the frames were collected. 
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e End-of-file record 


The first record in the file is always a version record, the last is always 
an end-of-file record, and those in between are usually (but not 
necessarily) frame records. 


There is no explicit encoding of the file’s total length (except as part of 
its directory entry). 


Header 
Every record, of any type, begins with the following header: 
struct f_recstruc { /* Standard record header. */ 
int type: /* Type of this record. (Int = 2 bytes) */ 
int length; /* Length of remainder of this record. ¥/ 
int rsvd; /* Reserved word, currently 9. */ 


g; 
The header’s first field indicates what type of record follows. The 
three principal types are identified by the following values: 


define REC_VERS 1 /* Version record (f_vers). sd 
tidefine REC_FRAME2 4  /* Frame data (f_frame2). */, 
define REC_EOF 3. /* End-of-file record (no data follows). ¥*/ 


Types other than these are reserved for future or other use. If you 
write a program to process data files, you should have it skip any 
record that isn’t one of these types. The length field indicates how 
much data to skip. 


Format of a Version Record 


struct f_vers_struct i 


int maj_vers; /* Major version of the analyzer */ 
int min_vers; /* Minor version of the analyzer */ 
struct date_struct date /* Date & time (4 bytes, DOS format) * 
char type; /* What type of records follow. my 
char network; /* An indicator of the network type. ie 
char format; /* An indicator of the format version. *Y 
char timeunit; /* An indicator of the frame timestamp unit. */ 
int rsvd{ 31; /* Reserved words. */ 


The possible values of network are as follows: 


idef ine NETWORK TRING §  /* Token ring */ 
iidef ine NETWORK_ENET 1 = /* Ethernet */: 
tdef ine NETWORK_ARCNET 2 /* ARCNET Hf 
iidef ine NETWORK_STARLAN 3. /* StarLAN ef 


si 


Data Exported to Printer or to File 


tidef ine NETWORK_PCNW 4 /* PC Network broadband */ 
tdef ine NETWORK _LOCALTALK 5 /* LocalTalk */ 
idef ine NETWORK_ZNET 6 = /* Znet xf 
idef ine NETWORK_SYNCHRO 7 /* WAN/Synchronous wl 


The possible values of timeunit are as follows: 


define TIMEUNITUNSPEC @ /* Unspecified; default by network type. */ 


define TIMEUNIT_PC 1 /* — §.838096 microsecond units */ 
define TIMEUNIT_3COM 2 /* 15900020 microsecond units */ 
define TIMEUNIT MICOM 3 /* 8.500028 microsecond units */ 
define TIMEUNIT_SYTEK 4 /*  2,689808 microsecond units ¥/ 


Format of a Frame Data Record 


Each record starts with a header, as described above, followed by data 
in the following structure: 


struct f_frame2_struct { 
unsigned time low; /* Low time, network-dependent units. af 
unsigned time_mid; /* Mid time, network-dependent units. */ 
char time_high: /* High time, network-dependent units. ef 
char time_day;: /* Time in days since start of capture. ia! 
int size; /* Number of bytes actually written in this file 

(may be less than frame's original length). yf 
char fs; /* Frame error status bits. */ 
char flags; /* Buffer flags; for internal use. I 
int true_size; /* If nonzero, the size of the original frame 

(since this frame has been truncated). */ 

int rsvd; /* Reserved; currently @. 

The frame data follows. */ 


All multibyte arithmetic fields (computed by the Sniffer analyzer 
during capture) are stored with the least significant byte first. Frame 
data are stored in the byte order transmitted. 


Format of an End-of-file Record 


The end-of-file record has no data; it consists only of the record 
header. 
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CHAPTER SEVEN: PROTOCOL INTERPRETER COMBINATIONS qT 


Network 


Chapter 7. Protocol Interpreter Combinations 


Chapter Overview 


The Configuration Utility permits you to build or remove alternate 
versions of the Sniffer analyzer software on the server. 


When you build a new analyzer, you specify the particular 
combination of protocol interpreter suites it will include. This permits 
you to create an analyzer that contains just the protocol interpreter 
suites you specify. Protocol suites are so numerous, and the 
individual protocol suites so large, that it is not possible to put all of 
them in a single analyzer. 


The Configuration Utility automatically adds each new analyzer to 
the server’s main selection menu, and automatically removes it from 
the menu when you delete one. 


Need for Particular Combinations of Interpreters 


With the Sniffer analysis server, Network General supplies all its 
protocol interpreter suites. However, you wouldn't really want all of 
them installed at once in the same analyzer. Moreover, they won't all 
fit in a single analyzer, anyway. So Network General delivers two 
versions of the analyzer and also gives you the ability to generate 
other combinations as needed. 


The Configure Server menu includes an option for Protocol 
Interpreter Combinations. By selecting it, you can build whatever 
combinations you want, subject only to limitations on the total size of 
the resulting program. 


Telling the Various Analyzers Apart 


Looking at the left side of the server's Main selection menu, you'll 
always see an entry for the Sniffer monitor and entries for at least two 
versions of the Sniffer analyzer (Figure 7-1). Here’s how you can tell 
the various analyzers apart. When you move the highlight to one of 
them, the help line below the panel lists its protocol interpreter suites. 
No two analyzers have the same list of interpreter suites. In Figure 7— 
1, the highlighted analyzer has suites for DECnet and X Windows. 
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tn 
Sniffer Server 


(c) Copyright 1999-1991, Network General Corporation 


Ethernet Monitor File Transfer Utility 


Ethernet Analyzer Configure Server 
thernet Analyzer Exit to the Operating System 


Suites: DECnet, XWindows 


e arrow keys to select, then press Enter. 


Figure 7-1. Distinguishing between analyzers in the selection menu. 


Looking at the right side of the server’s Main selection menu, three 
choices are visible: 


* File Transfer Utility (described in Distributed Sniffer System: 
Installation and Operations Manual) 


* Configure Server (mostly described in Distributed Sniffer 
System: Installation and Operations Manual) 


* Exit to the Operating System. 


The second of these, Configure server, contains (among other things) 
the option Protocol Interpreter Combinations, described in the rest of 
this chapter. 


Need for Particular Combinations of Interpreters 


onfigure Analysis Server: 


Server Parameters 


Protocol Interpreter Combinations 
Return to the Main Menu 


Run the Protocol Interpreter configuration utility. 


se arrow keys to select, then press Enter. ————— 


Figure 7-2. Protocol interpreter combinations in the Configure menu. 


You need Protocol Interpreter Combinations only to build a version of 
the Sniffer analyzer with a different combination of protocol 
interpreter suites. For example, suppose your server is initially 
configured with two analyzers, one with protocol interpreter suites 
for TCP/IP, Sun, ISO and X Windows, the other with DECnet and X 
Windows (Figure 7-3). Suppose you want in addition to build an 
analyzer having TCP/IP, DECnet and X.25. 


As delivered As you wish 
by Network General to build 


Ethernet analyzer | Ethernet analyzer Ethernet analyzer 
[file ENSN3BGQ. EXE] [file ENSNSG8@. EXE] [file ENSN288. EXE] 


1304 TCP/IP 1301 IBM 1304 TCP/IP 
1305 Sun 1302 Novell 1307 DECnet 
1307 DECnet 1303 XNS/MSNET 1312 X.25 
1309 VINES 1306 ISO 

1310 AppleTalk 1312 X.25 

1311 X-Windows 


Figure 7-3. Example: existing and desired combinations of protocols. 


To build the new analyzer, you select Protocol interpreter 
combinations and tell the configuration program the protocols you 
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want. It generates a new executable file. Like the other analyzers, the 
new one appears in the selection menu as Ethernet analyzer, but with 
its own distinct list of protocols when you highlight its name.! 


The analysis server has a copy of the Microsoft Quick C Compiler. It 
resides in the subdirectory QC2 within the TOOLS directory. You 
don’t run the compiler yourself; the configuration program does that 
automatically. 


Building a New Analyzer 


KO To build a Sniffer analyzer with a new combination of protocols 
S 


1. From the server’s Main selection menu, move the highlight to 
Configure server and press Enter. 


Result: The server opens the submenu headed Configure 
Analysis Server. 


2. Move the highlight to Protocol Interpreter Combinations and 
press Enter. 


Result: The server starts the Configuration Utility, and displays 
its initialization screen (Figure 7-4). 


The Sniffer Network Analyzer 
Configuration Utility 


Version 1.13 


Network General Corporation 
(C) Copyright 1986-1989 


4 Press any key > 


Figure 7-4. The Configuration Utility's initialization screen. 


1. Ifyou exit to the operating system and examine the names of executable files, you'll see 
that each of the various analyzers appears to DOS to have a name in the form 
xxSNxxxx.EXE. Those names are explained in “Names for the Sniffer Analyzer’s 
Executable Files” on page 6-5. They’re also shown in square brackets in Figure 7-3 


=e 


Building a New Analyzer 


Result: When you acknowledge the Press any key message, the 
Configuration Utility brings up its main menu (Figure 7-5). 


Network 
General 


Sniffer (tm) 
Network Analyzer Build Sniffer «| |>Ethernet 
Configuration Delete Sniffer # 
4 


Utility Exit 


Yersion 1.43 
(C) Copyright 
1986 - 1989 


Create a new Sniffer Network Analyzer 
for a selected network and protocol interpreters. 
ise the arrow keys to move, or ENTER to do this function 


Figure 7-5. The Configuration Utility's main menu. 


3. 


In the Configuration Utility's main menu, move the highlight 
to Build Sniffer, and then to the right to select the target 
network. 


The next panel contains only one entry. It shows the type of 
network for which a new analyzer will be built (Ethernet, token 
ring, or WAN/synchronous). This may seem pointless: you 
have a radio control with only one choice. It’s there because the 
same configuration program also runs on a portable Sniffer 
analyzer. A stand-alone Sniffer analyzer can have interface 
cards for several different networks. In that case, you'd get a 
real choice here. 


From the network selection, move to the right to select the 
protocol interpreters you want (Figure 7-6). 
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4 XNS/MSNET 
¢ TCP/IP 
¢ SUN 

/ 180 

/ DECnet 
/ Banyan 
4 
ri 
4 


Build Sniffer < 
Delete Sniffer 
Exit < 


fiat thernet 


AppleTalk 
XWindows 


Should the new Sniffer software run on Ethernet? 


Press space to select this option=——= 


Figure 7-6. Choices of network and interpreter in the Configuration Utility. 


5, 


Within the list of protocol interpreters, move the highlight 
vertically to select a protocol interpreter and press Spacebar to 
toggle between / (include) and x (exclude). Press Alt-Spacebar 
to reverse all the settings. 


Make a judicious choice of protocols. It’s hard to give specific 

advice here. Obviously, you want to include protocols likely to 
occur together. At the same time you don’t want to include any 
that are unnecessary, since one of the objectives is to limit the 

total size of the analyzer to be built. 


The various protocol interpreter suites differ in size. The space 
required for a particular combination is not the sum of their 
separate parts. To be sure that what you request will fit into 
memory, you'll need to experiment. Even when the 
compilation runs successfully, the resulting executable may 
still be too large to execute. If so, you'll get an explanatory 
message when you try to start it. 


Once you've selected the protocol suites to be included, move 
the highlight back to Build Sniffer and press Enter. 


Result: The Configuration Utility displays a description of the 
Sniffer analyzer you propose to build and asks you to confirm. 
(If you ask for a combination of protocols that already exists, it 
points out that your proposed analyzer will replace an existing 
one, and asks you to confirm.) 


Confirm your wish to build a new analyzer by pressing Enter, 
or halt the build by pressing Esc. 


Deleting an Analyzer 


Result: When you press Enter to proceed, the configuration 
program puts up a screen headed Build progress. As it starts 
each phase of the build, it reports its progress by adding a 
check mark beside the name of that stage. There are four stages: 


* Building the configuration file 
* Compiling 

* Linking 

* Post-link processing 


At completion, the configuration program displays the 
message 
xxx Sniffer Network Analyzer successfully built. 


If the utility encounters an error during the process, you'll see 
a summary error message. This message may tell you where 
the Configuration Utility has written a more detailed error 
report. 


When you exit from the Configuration Utility, you are returned to the 
selection menu. The Sniffer analyzer that you just built has now been 
added to the menu. It’s ready to run in the same way as the other 
analyzers already installed. 


Deleting an Analyzer 


The menu in which you build a new analyzer also contains the choices 
to delete one. The task is simpler: you only have to identify the 
analyzer you no longer want. 


ne To delete an existing Sniffer analyzer 
Ko 1. From the server’s Main selection menu, move the highlight to 


Configure server and press Enter. 


Result: The server opens the submenu headed Configure 
Analysis Server. 


Move the highlight to Protocol Interpreter Combinations and 
press Enter. 


Result: The server starts the Configuration Utility, and displays 
its initialization screen (Figure 7-4). 


When you acknowledge the Press any key message, the 
Configuration Utility brings up its main menu (Figure 7-5). 
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In the Configuration Utility’s main menu, move the highlight 
to Delete Sniffer, and then to the right to select the analyzer to 
be deleted. 


The next panel contains a list of the analyzers that currently exist on 
the server. The description of each analyzer shows first the network it 
monitors, and (in the lower panel) the protocol interpreter suites 
included in the highlighted analyzer. (That’s why —if you look only 
at the center panel— the list of analyzers has several repetitions of the 
network name.) 


Build Sniffer 4d Ethernet 
Delete Sniffer ¢ 
Exit 4 erne 


Suites: Novell, XNS/MSNET, TCP/IP, SUN, ISO, DECnet, XWindows, X25 


=———=Press space to select this option= 


Figure 7-7. Identifying an analyzer to be deleted. 


4. 


Identify the analyzer to be deleted. As you move the highlight 
vertically from one analyzer to the next, the lower panel shows 
the list of protocol interpreters for the one you've highlighted. 
No two analyzers can have the same list of interpreters. 


To select the analyzer you want to delete, highlight its entry 
and press Spacebar to move the radio control's |> to that line. 


Having selected the analyzer to be deleted, return the highlight 
to Delete Sniffer and press Enter. 


Result: The configuration program displays a warning 
message (Figure 7-8). The message repeats the list of protocol 
interpreter suites of the analyzer in question. Press Enter to 
proceed with the deletion, or Esc to cancel. (If you delete an 
analyzer and subsequently decide you want it again, you have 
only to run the utility to rebuild it.) 


Deleting an Analyzer 


The Ethernet Sniffer will be deleted. 


Suites: Novell, XNS/MSNET, TCP/IP, SUN, ISO, DECnet, 
XWindows, X25 


Press ENTER to proceed. Press ESC to cancel, 


Figure 7-8. Warning before deletion of an analyzer. 
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tation 1-21 


8571/4 (FTAM), protocol interpreta- 
tion 1-21 
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1-21 
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ACSE, protocol interpretation 1-21 
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vs. higher level 5-7 
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—level: see separate entry for ad- 
dress level 
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—blank names limit in name table 
5-60 


—effect on name table 5-11, 5-61, 
6-15, 6-16 


—effect on scan for names 5-65 
—filter 1-19, 56, 5-7 
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—summary view 5-8 
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ADSP, protocol interpretation 1-21 
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Alt-Spacebar to reverse all selections 
1-28, 5-13 
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match 2-25 
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—vs. capture 2-3 
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—connect when already running 
1-21, 1-24 
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—delete 7-9 
—in selection menu 1-24 
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—procedure to build 7-6 
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—schematic diagram of flow 1-7 
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cast 1-5 
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AppleTalk 
—format of DDP address 5-26 
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—protocol interpreter suite 1-21 
application layer, OSI model 5-33 
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ASCII 
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—transliteration in hex view 5-34 
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5-29 


ASP, protocol interpretation 1-21 
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AUTOEXEC.BAT, file to start Sniffer 
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B, suffix in extension of binary file 
6-5 
backspace, example in pattern match 
2-29 
bandwidth, network utilization esti- 
mate 5-22 
Banyan VINES, protocol interpreter 
suite 1-21 
bar graph 
—linear vs. log scale 240 
—traffic density 2-43 
—units 2-39, 2-40 
BAT, file extension for batch DOS 
commands 6-4 
batch file 
—AUTOEXEC.BAT 6-7 
BBN, manufacturer code 6-18 
beacon, token ring 2-6 
BICC, manufacturer code 6-18 
binary 
—data for pattern match 2-25 
—field interpretation 5-28 
—pattern 2-25 
bit reversal 
—transmission of DLC address 
6-18 
bit-level interpretation 5-28 
Bridge, manufacturer code 6-18 
bridge, source routing information 
2-26 
broadcast 
—destination address 2-6 
—filter 2-11, 2-12, 5-6, 5-8 
—station address 2-13, 5-61 
buffer 
—flag in trace file 6-21 
—percentage full 2-5 
buffer: see also capture buffer 
build analyzer 7-6 
Build progress, message 7-9 
byte order, numeric field in trace file 
6-21 
bytes 2-48, 5-19 
—cumulative 5-21 


—display of count of traffic seen 
2-42 


—number in frame 5-22 
—sumary view 5-22 


—units 2-40 
—written, field in trace file 6-21 


C 


C compiler, configuration utility 7-6 
C, suffix in extension of trace file 
5-68, 6-5 
cable test 
—automatic 34 
—distance to fault 3-5 
—Ethernet 14 
—fault diagnosis 3-6 
—jittering display 3-6 
—menu option 3-3 
call 
—accepted, X.25 type 2-47 


—active vs. completed in LCN ta- 
ble 2-47 


—name for source or destination 
2-48 


—number count during capture 
246 


—request, X.25 type 2-47 
capture 

—actions following 1-12 

—automatic cable test 3-4 

—continuous 2-34 

—count X.25 or SNA 2-46 

—default setup 2-6 

—discard previous buffer 2-54 

—DLC address in filter 2-13 

—frame counts 2-39 

—from file of saved frames 2-3, 

2-54, 5-56 

—highspeed mode 1-10, 2-5, 2-50 

—introduction 1-8 

—menu options 2-36 


—monitoring vs. non-capture 
monitoring 2-3 


—names in display 2-9 

—options 2-5 

—options for stopping 2-34 

—pair counts 2-44 

—pause 2-53 

—preparations 2-4 

—saved setup 2-10, 5-72 

—skyline display 24, 2-5, 2-39, 
2-48 


—skyline scale adjustment 2-49 


—source live vs. playback from file 
1-8, 2-5, 2-49, 5-3 
—start 2-5, 2-52, 5-39 


Index 


—stop 2-53 
when buffer full 2-34 
—stopping point 2-5 
—time required for filters 2-11 
—traffic density units 2-39 
—trigger 2-5 
—trigger to stop 2-33 
—vs. analysis 2-3 
—vs. display 14 
—WAN/synchronous example 
2-47 
capture buffer 


—automatic scan for addresses 
5-12 


—capacity 1-11 

—diagram 1-7 

—discard at new capture 2-54 
—display frames 1-13, 54 
—filled during capture 1-12, 2-3 


—load with file of saved frames 
5-68 
—not in saved setup 5-72 
—overflow 2-34 
—percent full report 2-43 
—position of trigger frame 2-34 
—report on frames 5-51, 6-19 
—report size 2-37 
—role 5-3 
—save to file 1-13, 2-54, 5-68, 5-69, 
6-8 
file format 6-19 
—temporary storage of accepted 
frames 2-3 
CAPTURE directory 6-8, 6-10, 6-11, 
6-13 
capture filter 1-8, 1-9, 2-5, 2-10 
—defective frames 2-44 
—diagram 1-7 
—direction on WAN 2-5 
—menu option 2-10 
—pattern match 2-5, 2-20 
example 2-29 
—protocol 2-5, 2-18 
—saved setup 5-71 
—types 2-11 
—unknown station 2-5 
captured frames file: see trace file 
CAPTURING (message) 2-36 
case in search for text 5-40 
Cayman, manufacturer code 6-18 


CDC, manufacturer code 6-18 


CFG, file name extension for analyz- 
er configuration 6-4, 6-7 


change path 6-9 
character 
—data for pattern match 2-25 
2-25 


—transliteration of ASCII or EB- 
CDIC 5-33, 5-34, 5-35 


Cheapernet, propagation speed 3-5 
check list, menu 1-28 

CIMlinc, manufacturer code 6-18 
cisco, manufacturer code 6-18 


clear 


—counters during capture 2-44, 
2-45 


—name table 5-64 

—request, X.25 type 2-47 
CLNS, protocol interpretation 1-21 
CMC, manufacturer code 6-18 
CMOT, protocol interpretation 1-21 
collision 4-5 

—effect on cable test 3-6 


—fragment 
filter 5-14 
flag 5-21 


color 
—layers of OSI model 1-17, 5-33 
—monitor 5-33 

combining patterns 2-21, 2-23 


ComDesign, manufacturer code 
6-18 


comment in name table 6-15 

compile, stage in configuration utili- 
ty 7-8 

compiler, for configuration utility 
7-6 

compiling, message 7-9 

completed call, LCN table 2-47 

CONKHIG, directory 6-7 

COMNFIG.SYS, file 6-7 


configuration 
—file to describe network interface 
for configuration menu 6-7 


—server 7-4 


—utility 1-20, 7-3 

build new Sniffer file 7-8 
compiler 7-6 
error message 7-9 
generates Sniffer menu items 6-7 
selection of protocol suites 7-8 
when needed 7-3 

configure server 1-24 


console 
—more than one to same server 
1-24 
—print reports from server 5-52 
—trelation to server 1-21 
—time-out 4-3 


copy 
—capture buffer 1-12 


—pattern and offset 5-36 


counter 
—bytes 1-10 
—capture 2-5 
—frames 1-10, 2-39, 2-41 
—kilobytes 1-10, 2-39 
—source 2-39 
—source address 2-41 
—source and destination 2-39 


—suppressed during highspeed 
capture 2-50 


—traffic 24 
Courier, protocol interpretation 1-21 
CRC error 
—filter 2-11, 2-31, 5-7, 5-14 
—flag 5-21 
create directory 6-9 
CSV 


—comma separated values file 
5-53, 5-54 


—comparison of file and screen 
output 5-56 


—effect on detail or hex views 5-56 
—file extension for formatted data 
64 
CTERM, protocol interpretation 
1-21 
CTS, synchronous line status indica- 
tor 2-43, 2-47 
cumulative bytes 5-19, 5-21 
—summary view 5-22 
cursor keys 
—horizontal scrolling 5-39 
—next line or frame 5-38, 5-39 


—to pass from display to pattern 
entry 2-28 
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—to scroll LCN table 2-47 


cut and paste 
—-pattern and offset 5-36 


D 
D, suffix in extension of name file 
5-60, 6-5, 6-10 
DAP, protocol interpretation 1-21 
data 
—file name 6-10 
—generated frame content 4-3 
—load 2-54, 5-68 
—rate 1-10 
Data General 
—manufacturer code 6-18 
data relative offset 2-7, 2-26 
date format in trace file 6-20 


days since start, field in trace file 
6-21 


DCA, manufacturer code 6-18 
DCE 

—count during capture 2-46 

—filter 2-11 

—frame count 2-41 

—tabulation in skyline 2-48 
DDP 

—address format 5-26 

—-protocol interpretation 1-21 
deactivate pattern 2-22 
DEC, manufacturer code 6-18 
DECnet 

—interpreter suite in configuration 

utility example 7-5 

—manufacturer code 6-18 

—protocol interpreter suite 1-21 
default 

—capture 2-6 

—directory 6-13 

—setup restored 6-12 
DEFAULT.xxS, file 6-13 
defective frame 

—capture filter 2-5 


—example in pattern match 2-29 
delimited format 5-54 
delimiter, CSV format 5-53, 5-54 
delta time 5-19, 5-22 
density 

—scale 2-41 

—traffic bar graph 2-4, 2-43, 2-48 

—traffic display 1-10 
destination address 

—counter 2-4 

—filter 2-11, 2-14 

—generated frame 44 

—generic 2-12 

—logical call 2-48 

—omitted in two-station format 

5-18 

destination class 

—filter 1-9, 2-5 

capture 5-6 
display 2-11, 2-12, 5-8 

—RI bit 2-7 
destination port 

—-pattern match example 2-23 
detail view 1-15, 1-16, 5-15, 5-23 


—continuation to following frame 
5-37 
—CSV format 5-56 
—display 5-4 
—format of higher level address 
5-25 
—highlight corresponding hex 
view 5-35, 5-37 
—level initially displayed 5-25 
—position 5-15 
—protocol level 5-25 
—-screen vs. printed 5-54 
—search for text 1-19, 5-41 
—synchronization with summary 
view 1-17, 5-25, 5-28, 5-39 
—treatment of “address recog- 
nized” bits 5-32 
DG, manufacturer code 6-18 
diagram of flow of frames 1-7 


dictionary of station names: see 


—default 6-13 
—DOS 6-7 
—ENSNIFF 6-8 
—in dialog box to select file 568 
—organization 6-6 
—path not in saved setup 5-72 
—path to a different 6-9 
—root 6-7 
—saved capture files 6-8 
—SYSNIFF 6-8 
—TOOLS 6-8 
—TRSNIFF 6-8 
—xxSNIFF 6-8 
disconnect 
—HDLC type 2-47 
—token ring 2-6 
display 1-16 
—address level 1-19 
—automatic scan for station ad- 
dresses 5-12, 5-60, 5-65 
—capture buffer 1-13, 2-54 
—detail view 5—4, 5-15, 5-25 
—format 
two-station 5-18 
—hex view 5-4, 5-15, 5-33 
—highest-level only 5-17 
—menu 5-4 
—name width 5-16 
—options 5-5, 5-38, 5-40, 5-42, 
5-43 
—options, function key 5-38 
—role of capture buffer 5-3 
—screen vs. printed 5-54 
—search 
for pattern 1-18, 5-38, 5-42, 5-43 
for text 1-18, 5-38, 5-40, 5-42 
—server seen from console 1-21 


—skyline vs. meters during cap- 
ture 1-10 


—start 54 

function key 5-38 
—summary view 5-4, 5-14, 5-15 
—summary vs. detail vs. hex 1-15 
—two viewports 5-4 
—vs. capture 1-4 


—filter 2-31, 2-44, 5-7, 5-14 name table —width of name field 5-17 
—overlapping categories 2-32 direction, capture filter 2-5 —width of time fields 5-20 
—total seen 2-43 directory display filter 1-12, 1-13, 1-18 
delay, traffic generator 4-6 —CAPTURE 6-8, 6-10, 6-13 —address level 5-6 
delete —CAPTURE vs. xxSNIFF 6-11 —defective frames 5-7, 5-14 
—analyzer 7-9 —CONFIG 6-7 —diagram 1-7 
—data file 5-70 —create new 6-9 —effect on saving frames 5-70 
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—menu 5-5, 5-6 
—pattern match 2-20, 5-6, 5-13 
—protocol 5-6, 5-13 
—save frames 5-69 
—saved setup 5-71, 5-72 
distance to cable fault 3-5 
distributed Sniffer system 1-3 
DLC 
—address 5-7 
—capture filter 2-13 
—header AC and FC bytes 4-11 
—level in name table 5-11 
—protocol 
6-byte address standards 5-27 
address format 6-16 
—SAP, protocol filter 2-18 
DN, HDLC type 2-47 
DNS, protocol interpretation 1-21 


don’t care character in pattern match 
2-22, 2-25 


don’t match 2-24 
DOS 7-4 
—directory 6-7 
—exit 1-24 
—path 6-7 
Dove, manufacturer code 6-18 
down arrow: see cursor down 
DRP 
—address format 5-26 
—protocol interpretation 1-21 
DSAP, example 4-11 
DSR, synchronous line status indica- 
tor 2-43, 2-47 
DTE 
—count during capture 2-46 
—filter 2-11 
—frame count 2-41 
—tabulation in skyline 2-48 


DTR, synchronous line status indica- 
tor 2-43, 2-47 


Echo, protocol interpretation 1-21 

edit name table 29, 5-61, 5-64 

either offset 2-23 

—with OR 2-24 

EN, network abbreviation in file 
name 6-5 

ENC, extension for file of captured 
frames 6-5, 6-10 

encoding, WAN/Synchronous op- 
tion 2-8 

Encore, manufacturer code 6-18 


end of file, trace file record 6-19, 
6-21 
End, cursor key 5-39 


END, extension for file of station 
names 5-66, 6-5 


ENI, extension for file of manufac- 
turer IDs 6-5, 6-17 
ENS, extension for file of setup spec- 
ifications 5-71, 6-5, 6-12 
ENSNIFF, directory 6-8, 6-11 
Enter key, menu action 1-28 
EOF, trace file record 6-19, 6-21 
Error 
—protocol interpretation 1-21 
error 
—building new analyzer 7-9 
—filter for defective frame 2-31 
—fragment 2-32 
—overlapping categories 2-32 
error status, field in trace file 6-21 
ES-IS Routing, protocol interpreta- 
tion 1-21 
Ethernet 
—cable test 14 
—highspeed capture 1-10 
—minimum frame size 2-32, 4-5 


—monitoring and transport using 
the same ring 1-5 


—multicast address 2-13 
—network code in trace file 6-20 


EXE, file extension for executable 
6-4 


executable file, utility to generate 
1-20, 7-3 

exit to DOS 1-24, 7-4 

extension, file name 6-3, 6-4 


external monitor 5-33 


F 
Fl 
—help xix, 2-53, 5-38 
F10 
—start capture 2-5, 5-39 
—stop capture 2-53 
F2 
—mark frame 5-52 
—move to next skyline 2-49 
—set mark 5-38 
—toggle active vs. completed calls 
2-47 
F3 
—display capture buffer 5-38 
—display data 54 
—force protocol 5-45 
F4 
—zoom 5-15, 5-38 
F5 
—return to main menu 5-38 
—scale up skyline 2-48, 2-49 
F6 
—display options 5-5, 5-40, 542, 
5-43 
—get display options 5-38 
—scale down skyline 2-48, 2-49 
FZ 
—go to previous frame 5-38 
—scroll up LCN table 2-47 
—view earlier skyline 2-48 
F8 
—go to next frame 5-39 
—scroll down LCN table 2-47 


cee ee se —propagation speed 3-5 —view later skyline 2-48 
: : —trigger example 2-36 F9 

arg character transliteration Bihentype 4-8 —pause capture 2-53 

—example 5-18, 5-24 fault 
E —generated frame 4-3, 4-8 —cable 3-3 
EBCDIC —protocol filter 2-18, 2-19 distance 3-5 
seach fir texk at Excelan, manufacturer code 6-18 FC byte, DLC header 4-11 
—transliteration in hex view 5-34 exclude others field 

—address filter 2-16 
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—delimiter in CSV format 5-53, 
5-54 


—printed report 5-51 
—width of name 5-17 


file 


—capture from playback 1-8, 2-5, 


2-54 
—captured frames 2-3, 2-54, 5-3, 
5-56, 5-68, 5-69, 6-8 
format 6-19 
identifying extension 6-5 


—contrast with working memory 


5-64 
—delete 5-70 
—effect of display filter 5-5 
—extension 
for captured frames 6-5 
for manufacturer ID 6-5 
for name table 6-5 
for setup 6-5 
—menu option 5-68 


—name for Sniffer analyzer soft- 
ware 6-5 


—name table 6-10 
format 6-13 
—naming conventions 6-3, 6-4, 
6-10 
—open (trigger example) 2-36 
—playback of capture 2-49 
—printer output 5-51, 5-52, 6-19 
—-save capture buffer 1-13 
—saved setup 5-72 
—setup 2-4 
—transfer 1-24, 7-4 
filter 
—address 2-14 
any station 2-16 
DLC 2-13 
example 2-16 
fewer than four matches 2-16 
order of checking 2-17 
procedure 5-10 
select station by name 5-11 
—address level 1-19, 5-6, 5-7 
selected name 5-11 
—alignment error 2-11 
—broadcast 5-6 
—capture 1-8, 2-5, 2-10 
list of types 2-11 
pattern match 2-20, 2-29 
saved setup 5-71 
—CRC error 2-11 


—defective frames 2-31, 2-44, 5-7 
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—destination class 1-9, 2-5, 2-11, 
2-12, 5-6, 5-8 
—diagram 1-7 
—display 1-12, 1-13, 1-18, 5-5 
pattern match 2-20 
saved setup 5-71 
saving data 5-70 
—display vs. capture 1-18 
—higher level address 1-19 
—higher level protocol 2-3, 2-20 
—introduction 1-8 
—joint effect of several 2-10, 2-16 


—pattern match 1-9, 2-11, 5-6, 
5-13 
—-protocol 1-9, 1-18, 2-11, 5-6, 
5-13 
ARCNET network code 2-18 
Ethertype 2-18 
SAP 2-18 
—saved setup 5-72, 6-10 


—-station address 1-9, 2-13, 5-6, 
5-9 

—time required during capture 
2-11 

—unknown station 1-9, 2-5, 2-11, 
2-12 


filtered only, option in saving data 
5-70 
flag 
—alignment error 5-21 
—CRC error 5-21 
—FLAGS option 5-19 
—Flags option 5-20 
-—fragment 5-21 
—lost frame 5-21 
—mark 5-21, 5-22, 5-38 
—trigger frame 2-36 
flag in summary view 5-20 
force protocol 5-44 
—F3 key 5-45 
form feed, printed report 5-57 
format 
—file of captured frames 6-19 
—higher level address 5-25 
—name table 6-13, 6-14, 6-15 
—printed report 5-51, 6-19 
—station address 5-16 
—version record in trace file 6-20 
FOUND, protocol interpretation 
1-21 
fragment 4-5 
—capture filter 2-31, 2-44 


—display filter 5-7, 5-14 
—error classification 2-32 
—flag 5-21 
fragmentation protocol 
—OS] layered model 5-33 
frame 
—captured and saved to file 2-54, 
5-68, 5-69 

file format 6-19 
—copied by Sniffer analyzer 5-32 
—count 2-39, 2-41 

units 2-40 
—counter 2-5, 2-48 
—defective 2-5, 2-11, 5-20 

filter 2-31, 5-7 

total seen 2-43 
—discarded 

at new capture 2-54 

when buffer full 2-3 
—display 2-54 
—field in trace file 6-19 
—filter to limit capture 1-8 
—go to number 5-38, 5-39 
—good (in filter) 2-31 
—jump to mark 5-38 
—jump to trigger 5-38, 5-39 
—lost 

highspeed capture 2-50 

total 2-43 
—marked 5-20 
—minimum size 2-32, 4-5 
—number 5-19 
—dquantity to generate 4-6 
—range in printed report 5-51 
—scroll to next or previous 5-38 
—search pattern 2-20, 5-38, 5-42 
—sequence number 4-12 
—size 2-5, 2-37 
—storage following capture 2-3 
—timestamp 1-8 
—trigger when detected 5-20 


—truncate for storage 2-3, 2-5, 
2-38 


—validity checks 5-32 
frame copied, token ring 5-32 


frame error status, field in trace file 
6-21 


frame relative offset 2-7, 2-26 


frame type, WAN/synchronous op- 
tion 2-8 


frames per second 
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—capture display 1-8, 1-10, 2-43, 


2-45, 2-49 
—generated 4-10 
FRMR, HDLC type 2-47 


from frame n 
—range printed 5-52 


FRP, protocol interpretation 1-21 


FTAM, protocol interpretation 1-21 


FTP, protocol interpretation 1-21 
full buffer 
—capture 2-3, 2-34 
function keys 
—display options 5-38 
—help 5-38 
—menus 5-38 
—new capture 5-39 
—next frame 5-39 
— pause or resume capture 2-53 
—previous frame 5-38 
—set mark 5-38 
—stop or start capture 2-53 
—zoom 5-38 


functional address 2-13 


G 

gateway, RI field 2-8 

generate traffic 1-4, 4-3 
—diagram 1-7 

GGP, protocol interpretation 1-21 

go to frame number 5-39 


good frame 
—filter 2-31, 5-14 
—total 2-43 


Gould, manufacturer code 6-18 


H 
hard disk directory structure 6-6 
HDLC 
—count by type 2-47 
—protocol interpretation 1-21 
—WAN/synchronous option 2-8 
header 


—effect of truncating stored frame 


—data for pattern match 2-25 
—pattern 2-25 
—station address 2-15 


hexadecimal view 1-15, 1-16, 5-15, 


5-33 
—character transliteration 5-33 
—color in display 5-33 
—CSV format 5-56 
—display 54 
—dynamic choice of character 
transliteration 5-35 


—highlight corresponding detail 
view 5-35, 5-37 


—position 5-15 
—search for text 5-41 

hidden protocol 5-44 

higher level address 
—display 5-17 
—display format 5-25 
—filter 1-19, 5-6, 5-7 
—scan for names 5-65 

higher level protocol 1-16 
—address formats 5-26 
—filter 2-20 


—frames that span several DLC 
frames 5-36 


—interpretation 5-28 
—name table 5-63 
highest level only 
—effect on detail 5-25 
—-screen vs. printed 5-55 
—summary view 1-16, 5-17 
highlight 
—coordination of views 1-17 


—hex corresponding to detail in- 
terpretation 5-35, 5-37 


—menu selection 1-23, 1-26 
high-order-bit first 

—transmission order 5-27, 6-18 
highspeed capture 2-5, 2-50 

—Ethernet option 1-10 


highwater 
—traffic density 2-43 
—traffic density bar graph 2-39 


Home, cursor key 5-39 


| 

I, suffix in extension of manufacturer 
ID file 5-16, 6-5, 6-10, 6-17 

IBM 


—Network Management, protocol 
interpretation 1-21 


—protocol interpreter suite 1-21 

—protocol suite example 2-36 
ICMP, protocol interpretation 1-21 
ICP, protocol interpretation 1-21 
ID, manufacturer 6-10 

—station address 5-16, 6-17 

—table of names and codes 6-18 
IDP, protocol interpretation 1-21 
IEEE 

—802.2 2-6, 2-18, 2-26, 4-8, 4-9 

—802.2 and RI 2-7 

—802.3 4-8 

—802.3 and RI 4-8 

—standard for transmission of 

DLC address 5-27 
import name table for station ad- 
dresses 6-13 

include others, address filter 2-16 
individual count 

—clear 2-45 

—during capture 2-39 

—traffic by source 1-11, 2-45, 2-46 
Info, HDLC type 2-47 
initialization 

—name table 5-60, 6-13 

—setup file 5-72 
Intel, manufacturer code 6-18 
Intergraph, manufacturer code 6-18 
Interlan, manufacturer code 6-18 
interpretation 

—role of capture buffer 5-3 

—search for text 541 
interpreter: see protocol interpreter 
interrupt, X.25 type 2-47 
interval 

—network utilization 5-23 

—skyline 2-5 


; ee 6-20 horizontal scrolling 5-39 —traffic generator 4-6 
— ay . . 
; H-P Intelligent Networks Oper, intruder: see unknown address 
heading, printed report 5-56 manufacturer code 6-18 iP 
help H-P, manufacturer code 6-18 —address format 5-25, 6-16 

—F1 xix, 2-53, 5-38 —address level 5-7 
hexadecimal —example 5-24 
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—filter 2-19 

—level in name table 5-11 

—protocol interpretation 1-21 

—protocol number for TCP 2-29 
IPC, protocol interpretation 1-21 
IPX, protocol interpretation 1-21 


IRMA 
—terminal emulation protocol 
5-49 
ISO 


—frames that span several DLC 
frames 5-36 


—interpretation of ASN.1 5-29 
—interpreter suite in configuration 
utility example 7-5 

—NetBIOS 

protocol interpretation 1-21 
—-presentation 

protocol interpretation 1-21 
—protocol interpreter suite 1-21 
—session 

protocol interpretation 1-21 
—spanned frames 2-38 


ISODE, protocol interpretation 1-21 


J 

jump 
—to frame number 5-38, 5-39 
—to marked frame 5-38, 5-39 
—to menu item 5-68 
—to trigger frame 5-38, 5-39 


K 
kilobytes 
—counter during capture 2-5 


—display of count of traffic seen 
2-42 


—per second propagation 3-5 
—units 2-40 


Kinetix, manufacturer code 6-18 
KSP, protocol interpretation 1-21 


L 


LAN Manager 
—protocol interpretation 1-21 


—token ring functional address 
1-5 


LAN, capture filters 2-5 
LAP, protocol interpretation 1-21 
LAT, protocol interpretation 1-21 


layer 
—detail view 5-25 
—ISO model 1-17 
—OSI model colors 5-33 
—-protocol 1-13 
LCN 
—active vs. completed calls 2-47 


—address not determined in frame 
2-47 


—count during capture 2-46 
—table 2-47 
length 
—field in trace file header 6-20 
—frame 5-19 
—generated frame 4-3 
—printed page 5-57 
—RI field 4-9 
level 
—address 1-19 
filter 1-19, 5-7 
summary view 5-8 
—all vs. highest only 5-17 
—highest only 1-16 
—initially displayed in detail view 
5-25 
—name in address filter 5-11 
—summary view 1-16 
line status, WAN/synchronous 2-43 
linear scale 2-5 
—skyline 2-49 
—traffic density bar graphs 2-40, 
2-41 
lines per page 5-57 
link 
—layer, OSI model 5-33 
—stage in configuration utility 7-8 
linking, message 7-9 
live capture 2-49 
LLC 
—protocol interpretation 1-21 
LLC, transliteration of characters in 
hex view 5-35 
load 


—file of captured frames 2-54, 5-3, 
5-56, 5-68 


—setup 5-72, 6-10, 6-11 
LocalTalk 
—network code in trace file 6-20 


location: see offset 


logarithmic scale 2-5 


—traffic density bar graphs 2-40, 
2-41 


logic, combination of several pat- 
terns 2-19, 2-21, 2-23, 2-30 
logical call 2-47 
—name 2-9 


—name for source or destination 
2-48 


—number: see LCN 
look for names 2-9, 5-61, 5-65 
LOOP, protocol filter 2-19 
lost frame 
—effect of capture filter 2-11 
—effect of truncation 2-38 
—flag 5-21 
low-order-bit first 
—transmission order 5-27, 6-18 
LPT1, printer output to server 5-52 
LPT2, printer output to console 5-52 


LTC, extension for file of captured 
frames 6-10 


M 
M, marked frame 5-20 
MAC 
—protocol filter 2-19 
—-protocol interpretation 1-21 
—transliteration of characters 5-35 
Mail, protocol interpretation 1-21 
main menu 1-25, 1-27 
main menu: see also selection menu 
make directory 6-9 
manage names 
—name table 5-59 
manufacturer ID 
—file extension 6-5 
—file format 6-17 
—name in station address 5-16 
—table of names and codes 5-16, 
6-10, 6-18 
MAP/TOP 3.0 (ISO NetBIOS, proto- 
col interpretation 1-21 
mark 


—default range of frames printed 
5-52 


—flag 5-21, 5-22 
—function key 5-38 
—jump to 5-38, 5-39 

match 
—enable/ disable 2-16, 2-22 
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—fewer than four 2-16 
—name for 2-14, 2-20 
—order of checking 2-17 
—vs. don’t match 2-24 


Match 1, name for filter element 
2-14, 2-20, 5-10, 542 


Matchmaker, protocolinterpretation 
1-21 
memory 
—report of allocation 2-37 
—representation of transmitted 
address 5-27 
menu 
—detail display 5-4 
—display 54 
—display filters 5-6 
—function key during display 5-38 
—generated by .MNU files 6-7 
—hex display 54 
—jump to item 5-68 
—main 1-27 
—options vs. actions 1-27 
—panels 1-26 
—selection 1-20, 7-4 
—summary display 54 
MENU.EXE, executable file to man- 
age selection menu 6-4 
Metaphor, manufacturer code 6-18 
meter, traffic density 1-10 
Microsoft Quick C Compiler 7-6 
minimum frame size 4-5 
MIPS, manufacturer code 6-18 


misaligned frame: see alignment er- 
ror 


MNU, file extension for menu file 
6-4, 6-7 

modulo 8 or 128, WAN/synchro- 
nous option 2~9 

monitor 


—attached to same network used 
for transport 1-5 

—connect when already running 
1-25 

—during capture 1-9 

—during capture vs. without cap- 
ture 2-3 

—in selection menu 1-24 


—name table shared with analyzer 
5-64 


—server 
connect when already running 
1-24 
—Sniffer Network Monitor 1-9 
—vs. capture 1-9 


MOP, protocol interpretation 1-21 
Mount, protocol interpretation 1-21 
move to next panel 5-38 


moving average of network utiliza- 
tion 5-23 


multicast destination address 2-13 


N 


name 
—duplicate 5-64 
—during capture 2-9 
—effect of address level filter 5-8 
—field width in display 5-16, 5-17 
—file 6-3 
extension 64 
—file of captured frames 6-10 
—generic address 2-12 
—in summary view 5-16 
—LCN call address 2-47 
—look for 1-15, 2-9 


—manufacturer of interface card 
5-16 


—match in filter 2-14, 2-20, 5-10 

—resolve from file 1-14, 2-9 

—Sniffer analyzer’s executable file 
6-5 

—source or destination of logical 
call 2-48 


—station 2-9 
—station in address filter 5-11 
—symbolic equivalent for station 
address 1-14, 2-9, 5-59, 6-16 
name table 1-14 
—add entries 5-12 
—additions 
during capture 5-61 
during display 5-61 
—alphabetization 6-17 
—automatic scan for entries 5-12, 
5-60, 5-65 
—blank name limit per address 
level 5-60 


—clear 5-64 

—comment 6-15 

—contrast with saved file 5-64 
—create new 6-14 

—default type 6-16 


—edit 5-61, 5-63, 5-64 
—effect 

of address level 5-61 

on capture 2-9 

on display 2-9 

on filter 2-9 

on unknown stations filter 2-9 
—explicit and implicit declarations 

of address type 6-16 

—file 6-11 

extension 6-5 

format 6-13, 6-14, 6-15 

organization 6-10 
—higher level scan 5-65 
—import from file 5-67 
—initialization 5-60, 5-67 
—look for names 5-61 
—maximum size 5-60, 5-65, 5-67 
—new station 2-15 
—not in saved setup 5-72 
—protocol level 5-63 


—resolve from external file 5-61, 
5-66 


—save to file 5-61, 5-64, 5-67 
—shared by monitor and analyzer 
5-64 
—supplement by external file 6-13 
—symbolic equivalents 
for addresses 5-59 
found in network messages 
5-61, 5-65 
resolved from external file 5-67 
—type of address 6-15 
—unknown station 2-5, 2-12 
—unnamed station lost at save 
5-65 
—working table vs. saved file 5-13, 
5-59, 5-61 


NBI, manufacturer code 6-18 
NBP, protocol interpretation 1-21 
NCP, protocol interpretation 1-21 
ND, protocol interpretation 1-21 
Nestar 


—FS, protocol interpretation 1-21 
—IOB, protocol interpretation 1-21 
—manufacturer code 6-18 
—protocol interpreter suite 1-21 


NetBIOS 


—protocol filter 2-19 
—protocol interpretation 1-21 
—symbolic equivalent 5-61 
—trigger example 2-36 
—unexpected IRMA data 5-49 
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NetWare 
—protocol interpreter suite 1-21 
—protocol suite 
example 2-36 
network 
—field in trace file 6-20 
—role of Sniffer analysis server 14 


—transport vs. monitoring func- 
tions of server 1-5 
—utilization percentage 2-5, 2-39, 
5-19, 5-22 
Network Computing Devices, man- 
ufacturer code 6-18 


Network General, manufacturer 
code 6-18 


network interface card 
—description in .CFG file 6-7 
—unique DLC address 5-27 

network layer, OSI model 5-33 

Network Systems Corp, manufac- 

turer code 6-18 

network utilization 5-22 
—moving average 5-23 
—summary view 5-20, 5-22 


—window in which computed 
5-22 


new capture 

—F10 2-5, 5-39 
new directory 6-9 
new station 

—edit name table 2-15, 5-63 
next frame, function key 5-39 
NeXT, manufacturer code 6-18 
NFS, protocol interpretation 1-21 
NICE, protocol interpretation 1-21 
no signal 

—remove 

token ring option 2-6 

NOT, combining patterns 2-19, 2-21 
Novell 


—manufacturer code 6-18 
—system code 2-19 
Novell NetWare 
—-protocol filter 2-19 
—-protocol interpreter suite 1-21 
—protocol suite example 2-36 
—symbolic equivalent 5-61 
NRZ vs. NRZI encoding 2-9 
NSP, protocol interpretation 1-21 


number pages of report 5-56 
numeric field, byte order 6-21 


O 


offset 


—compensation for source routing 
information 2-25 


—cut and paste procedure 2-28 


—data relative vs. frame relative 
2-7 


—either 2-23 


—frame relative vs. data relative 
2-26 


—hex view 5-33 
—pattern 2-23, 2-25, 5-36, 5-42 
on-line help, F1 xix, 2-53, 5-38 
operating system, exit 1-24, 7-4 
option 
—in menu 1-28 
options 
—before capture 2-5 
—included in saved setup 5-71 
—menu 2-6 
—saved to file 6-10 
—WAN/synchronous 2-8 
OR 2-21, 2-23 
—combining patterns 2-19 
—with either offset 2-24 
order 
—bits within byte 5-27, 6-18 
—bytes in numeric field of trace 
file 6-21 
organization 
—directories 6-6 
—menus 1-27 
OS/2 LAN Manager, protocol inter- 
pretation 1-21 
OSI layer, color coding 5-33 
others 
—address filter 2-14, 2-16 
—capture filter 2-19 
output 
—printer 5-52 
—printer page titles 5-56 
—screen vs. printed 5-54 
—to file 5-52 


Pp 
Pl 
—X.400 protocol example 5-30 


packet 


—count by HDLC and X.25 types 
2-47 

—numbering on WAN/synchro- 
nous 2-9 


—type 
ASCII vs. EBCDIC translitera- 
tion 5-35 
WAN/synchronous option 2-8 


packet: see also frame 
PAD, protocol interpretation 1-21 
page 
—form feed to terminate 5-57 
—length 5-57 
—numbers in printed report 5-56 
—titles 5-56 
pair count 
—capacity of display 2-44 
—clear screen 2-44 
—during capture 1-11, 2-39, 2-44 
—example 2-44 
—source and destination 2-41 


panel 
—active 5-15 
—display 1-17 
—menu 1-26 
—scrolling 5-35 
—zoom 5-15, 5-38 


PAP, protocol interpretation 1-21 
parallel port 5-52 


paste 


—offset from display to pattern-- 
match entry 2-28 


—-pattern from display to pattern-- 
match entry 2-28 
path 
—different directory 6-9 
—DOS environment variable 6-7 
—not in saved setup 5-72 
—startup file 6-13 
pattern 2-21, 2-23 
—activate/deactive 2-22 
—binary data 2-25 
—capture filter 1-9, 2-5, 2-20 
—character data 2-25 
—contexts of use 2-20 
—cut and paste procedure 2-28 
—display filter 1-13, 2-20, 5-6, 
5-13 
—don’t care character 2-22, 2-25 
—don’t match 2-24 
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—example 2-29 
—filter 2-11 
—hexadecimal data 2-25 


—joint effect of several patterns 
2-30 


—logical combination 2-19 


—logical combination of compo- 
nent patterns 2-30 


—logical combination of matches 
2-21, 2-23 


—offset 2-23, 2-25, 5-36, 5-42 
—pair of components 2-23 
—procedure 2-26 
—procedure to set 2-20 
—saved setup 5-72 


—search for frame 1-18, 1-19, 2-20, 
5-38, 5-42, 5-43 


—trigger 1-12, 2-5, 2-20 
pattern matching: see pattern 
pause, capture 2-53 


PC Network 
—network code in trace file 6-20 


PCS, extension for file of setup spec- 
ifications 5-71 


PEP, protocol interpretation 1-21 


percentage utilization 2-5, 2-39, 
5-23 


—summary view 5-20 
PgDown, cursor key 5-39 
PgUp, cursor key 5-39 
physical layer, OSI model 5-33 


playback 


—capture from file 1-8, 2-3, 2-49, 
2-54 


—timing 1-8 
plus sign, detail view 5-37 
PMAP, protocol interpretation 1-21 


PNC, extension for file of captured 
frames 6-10 


port, pattern match example 2-23 
post-link processing 

—message 7-9 
PPP, protocol interpretation 1-21 


preferences, included in saved setup 
file 5-71, 6-10 


presentation layer 
—ISO protocol interpretation 1-21 


presentation layer, OSI model 5-33 


pre-trigger percentage, stop capture 
option 2-34 


previous frame, function key 5-38 
printed report 5-52 

—frames in capture buffer 1-13 
printer output 

—capture buffer 5-54 

—compared with screen 5-54 


—default values for range of 
frames 5-52 


—destination 5-52 
—diagram 1-7 
—format 5-51, 6-19 
—options in saved setup 5-72 
— page size 5-57 
—page titles 5-56 
—report 5-51, 6-19 
—width of text 5-24 
printer port 5-52 
PRN, file extension for printer out- 
put 5-53, 64 
propagation speed, cable test 3-5 
Proteon, manufacturer code 6-18 


protocol 
—capture filter 1-9 
—filter 1-18, 5-6, 5-13 
address level 5-6 
ARCNET network code 2-18 
capture 2-5, 2-18 
display 5-13 
display vs. capture 5-13 
Ethertype 2-18 
higher level 2-20 
SAP 2-18 
—forcing 5-44 
—high level address 5-7 
—higher level filters 2-3 
—higher-level 5-61 
—in summary view with high- 
est-level only 5-17 
—interpretation 1-13 
—layer 1-17 
—level and station name 6-16 
—level in detail view 1-16, 5-25 
—level in name table 6-16 
—name for address 5-59 
—screen vs. printed 5-54 
—unexpected 544 
protocol interpreter 5-28 
—address format 5-26 
—bit level 5-28 
—diagram 1-7 
—force recognition of protocol 
5-44 


—levels 1-14 
—RI 2-7 
—role of Sniffer analyzer 1-13 


protocol interpreter suites 
—build different combinations 7-5 
—list 1-14, 1-20 
—maximum number 7-8 


—represented in Sniffer file name 
6-5 


—selection in configuration utility 
1-20, 7-3, 7-8 
—supplied with server 1-20 


Pyramid, manufacturer code 6-18 


Q 

QC2, directory 6-8, 7-6 

QLLC, protocol interpretation 1-21 
Quick C Microsoft compiler 7-6 


R 


RAD Network Devices Ltd, manu- 
facturer code 6-18 


radio control 1-28 

range 
—frames in printed report 5-51 
—frames saved to trace file 5-69 


RARP, protocol interpretation 1-21 


real-time display during capture 
1-10, 2-43 


reflectometer 3-3 
REJ, HDLC and X.25 type 2-47 
relative time 5-19, 5-22 
remove from ring 
—option 2-6 
report 
—content of frames in capture 
buffer 5-51, 6-19 


—fields included 5-51 
—form feed 5-57 


—range of frames included 5-51 
default 5-52 


reset, X.25 type 2-47 


resolve names 1-14, 2-9, 5-61, 5-66, 
5-67, 6-13 


restart, X.25 type 2-47 
Retix, manufacturer code 6-18 


reverse direction 
—address filter 2-14, 2-15, 5-11 


RI, source routing information 
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—bit 2-6 
destination class 2-7 
generated frame 4-9 
IEEE 802.2 2-7 
—field 2-25 
format 2-8 
length 4-9 
—IEEE 802.3 4-8 
—interpreter 2-7 
—routers or gateways 2-8 
Ridge, manufacturer code 6-18 
RIP, protocol interpretation 1-21 
RNR, HDLC and X.25 type 2-47 
root directory 6-7 
Route, protocol interpretation 1-21 
router, RI field 2-8 
routing information 2-6, 2-8 
—generated frame 4-9 
RPC, protocol interpretation 1-21 
RPL, protocol interpretation 1-21 
RR, HDLC and X.25 type 2-47 


RS232, line status indicators 2-43, 
2-47 


RTMP, protocol interpretation 1-21 


RTP, protocol interpretation 1-21 


RTS, synchronous line status indica- 


tor 2-43, 2-47 


RUNIX, protocol interpretation 1-21 
RxC, synchronous line status indica- 


—effect of display filter 5-5 
—name table 2-9, 5-61, 5-64, 5-67, 
6-10 

alphabetization 6-15, 6-17 
caution 5-65 

—setup 1-15, 2-10, 5-70, 6-10, 6-11 
options included 5-71 

scale 
—linear vs. logarithmic 2-5, 2-41 
—skyline up or down 2-48, 2-49 


SCP, protocol interpretation 1-21 
screen vs. printed output 5-54 


scroll 
—display 1-18, 5-23 
—horizontal 5-39 
—LCN table 2-47 
—amultiple views 5-39 
—synchronization 
detail and hex 5-35 
detail and summary 5-25 
—to next or previous frame 5-38 
SDLC 
—-protocol interpretation 1-21 
—transliteration of characters 5-35 
—WAN/synchronous option 2-8 
search 
—frame 5-39 
—pattern 5-38, 5-42, 5-43 
captured frames 2-20 
case sensitive 5-40 


—relation to console 1-21 
—selection menu 1-22 
—time-out 4-3 
service access point: see SAP 
session layer 
—ISO protocol interpretation 1-21 
session layer, OSI model 5-33 
set mark, function key 5-38 
setup 
—automatic at startup 5-72 
—default values 2-6, 6-12 
—file 2-4, 2-6, 6-11 
—file extension 6-5 
—options saved 5-71 
—saved file 1-15, 5-70, 6-10 
—saved vs. current 2-10 
—start with customized 6-12 
side-by-side 
—two viewports 1-17, 5-4, 5-15 
—two-station format 5-18 
SilGrf, manufacturer code 6-18 
size 
—capture buffer 2-37 
—effect of truncating frame 2-38 
—frame 2-5 
—generated frame 4-5 
—minimum frame 4-5 
—minumim frame 2-32 
—number of bytes in frame 5-22 


tor 2-43, 2-47 during display 1-18 —printed page 5-57 
; offset 5-36 —stored frame 2-37 
RxD, synchronous line status indica- saved setup 5-72 . 
tor 2-43, 2-47 —station name 1-15 syne 2-2F 
text 5-38, 5-40, 5-42 —display during capture 1-10, 2-5 
S eee j —frames seen 2-48 
—text in frame 1-19 f DTE and f DCE2-4 
S, suffix in extension of setup file SELECT STATION ee oy vom 8 
a —interva 
pone ia ae —dialog box 2-15, 5-11 —kilobytes seen 2-48 
‘ ae selection menu 1-20, 1-24, 7-4 —-scale adjustment during capture 
SABME, HDLC type 2-47 —automatic invocation 6-7 2-48, 2-49 
SAP —multiple analyzers 1-20 —suppressed during highspeed 
—generated frame 4-3, 4-8, 4-11 —server 1-22 capture 2-50 
—identified at DLC level 2-19 sequence number, generated frame —tab to move from one to another 
—protocol filter 2-18 4-12 ae 
—protocol interpretation 1-21 Sequent, manufacturer code 6-18 geo ae ae 
—transliteration of characters in : 
hex view 5-35 wr ' —units 2~40 
avis —configuration 1-24, 7-4 —vertical scale linear or logarith- 
—connect when already running mic 2-49 
Bs ii oy ae 1-13, 2-54, 1-21,1-74 —view earlier or later 2-48 
diveetory 6-8 —anulple consoles 1-24 —which one is active 2-49 
file format 6-19 pore eo SLC, extension for file of captured 
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frames 6-10 
slicing: see truncation or frame size 
SLS, extension for file of setup speci- 
fications 5-71, 6-12 
SMB, protocol interpretation 1-21 
SMB, trigger example 2-36 
SMTP, protocol interpretation 1-21 
SNA 
—count during capture 2-46 
—protocol filter 2-19 
—protocol interpretation 1-21 
—transliteration of characters 5-35 
—unexpected protocol example 


—WAN/synchronous option 2-8 
SNAP, protocol filter 2-19 
SNAP, protocol interpretation 1-21 
SNDCP, protocol interpretation 
1-21 
Sniffer analysis server 
—directory structure 6-6 


Sniffer analyzer 
—build new executable file 7-8 
—delete 7-9 
—interpreter of protocols 1-13 
—multiple alternate executables 
7-3 
—name for executable file 6-5 
—name table shared with monitor 
5-64 
—procedure to build 7-6 
—role on network 14 
—schematic diagram of flow 1-7 
—startup 6-10 
—utility to generate executable 
files 1-20 
Sniffer distributed system 1-3 


Sniffer monitor 1-9 
—name table shared with analyzer 
5-64 
SniffMaster console, relation to serv- 
er 1-21 
SNMP, protocol interpretation 1-21 
SoftTalk, protocol interpretation 
1-21 
sort name table 6-17 
source address 
—count 2-41, 2-45, 2-46 
—filter 2-11, 2-14 
—logical call 2-48 


—omitted in two station format 
5-18 


source of capture 2-5 


source port, pattern match example 
2-23 
source routing information 2-6 
—compensation in offset 2-25 
—generated frame 4-9 
—length 4-9 
Spacebar, menu option 1-28 
spanned frame 
—detail display 5-36 
—effect of truncation 2-38 
speed 
—filtering during capture 2-11 
—Ppropagation 3-5 
—token ring 2-6 
Spider, manufacturer code 6-18 
SPP, protocol interpretation 1-21 


spread sheet 
—report for 5-51, 6-19 


SPX, protocol interpretation 1-21 
SSAP, example 4-11 
standby monitor, token ring 1-5 


StarLAN, network code in trace file 
6-20 


start capture 2-52 


startup 
—directories 6-11 
—files 5-60, 5-61, 5-64, 5-67, 6-10, 
6-11 
automatic use 6-12 
initial setup 5-72 
STARTUP.xxD 
—alphabetization of names 6-17 
—file 2-12 
—format of name table 6-13 


station 


—address: see listing under station 
address 


—name: see listing under station 
name 


—unknown 1-9, 2-5, 2-9, 2-11, 

2-12 
station address 5-59 

—additional name table 6-13 

—automatic scan captured frames 
5-12 

—bits in memory vs. bits on wire 
5-27 


—dialog box to select 2-15, 5-11 

—display filter procedure 5-10 

—display filter vs. capture filter 
5-9 


—filter 2-13, 5-6 
example 2-16 
—format 2-15 
—higher level 5-63 
—IEEE standard for bit order 5-27, 
6-18 


—inclusion of manufacturer ID 
6-17 


—level 5-11 

—name table 5-12, 6-10, 6-16 
—name table field 6-15 
—pair counts 2-41 

—pairs in side-by-side format 5-18 
—saved setup 5-72 
—spurious 2-44 

—symbolic equivalent 5-59 
—traffic generator 44 
—unique in name table 5-64 
—unknown 1-9, 2-11 
—width of display field 5-17 


station name 6-11 
—edit 5-61, 5-63, 5-64 
—look for 1-15 
—summary view 5-16 
—width in display 5-16 
status, RS232 indicators for line 2-43 


stop capture 2-53 
—buffer full 2-34 
—position of trigger frame 2-34 
StreetTalk, protocol interpretation 
1-21 
summary 
—highest level only 1-16 
—search for text 1-19 
—view 1-15 
Summary view 
—role in protocol forcing 545 
summary view 5-14, 5-15 
—CSV format 5-56 
—display 54 
—effect of address level filter 5-8 
—end key 5-39 
—fragment 5-21 
—highest-level only 5-17 
—home key 5-39 
—names 5-16 
—network utilization 5-20, 5-22 
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—position 5-15 
—screen vs. printed 5-54 
—search for text 5-41 


—synchronization with detail 
view 1-17, 5-28, 5-39 


—time 
absolute vs. relative 5-19 
—two-station format 5-18 
other frames 5-19 
—with detail view 5-25 
Sun 
—interpreter suite in configuration 
utility example 7-5 
—manufacturer code 6-18 
—protocol interpreter suite 1-21 
SY, network abbreviation in file 
name 6-5 


SYC, extension for file of captured 
frames 6-5, 6-10 


SYD, extension for file of station 
names 6-5 


SYI, extension for file of manufactur- 
er IDs 6-5, 6-17 


Symblx, manufacturer code 6-18 


symbolic equivalent 
—NetBIOS 5-61 
—Novell 5-61 


symbolic name: see name 


synchronization 
—views 1-17, 5-28, 5-39 


SYS, extension for file of setup spec- 
ifications 5-71, 6-5, 6-12 


SYSNIFF, directory 6-8, 6-11 
Sytek, manufacturer code 6-18 


—Telnet code 2-30 
TCP/IP 
—interpreter suite in configuration 
utility 7-5 
—-pattern match example 2-29 
—protocol interpreter suite 1-21 
Tektronix, manufacturer code 6-18 
Telnet 
—pattern match example 2-29 
—protocol interpretation 1-21 
—TCP code 2-30 
text 
—search 1-18, 5-38, 5-40, 5-42 
case sensitive 5-40 
interpretation 5-41 
—transliteration in hex view 5-34 
TFTP, protocol interpretation 1-21 
thermometer 
—traffic density 
linear vs. log scale 2-40 
—traffic density bar graph 2-43 
—units 2-40 
thin Ethernet 
—propagation speed 3-5 
TI, manufacturer code 6-18 
time 5-19 
—absolute 5-22 
—delta 5-22 


—example of various measures 
5-23 


—format in trace file 6-20, 6-21 


—network utilization window size 
5-22 


—relative 5-22 
—summary view 5-21 


—functional address 2-13 


—LAN Manager functional ad- 
dress 1-5 


—location in ring 5-32 
—monitor 1-5 


—monitoring and transport using 
the same ring 1-5 


—network code in trace file 6-20 
—remove automatically 2-6 
—speed 2-6 
—temporary disconnect 2-6 
—trace tool present” 1-5 
—trailer 5-32 
—transliteration of characters 5-35 
—trigger example 2-36 
TOOLS, directory 6-8, 7-6 
TOPS, protocol interpretation 1-21 
total 


—display of count of frames seen 
2-42 


—units 2-40, 2-43 
TP, protocol interpretation 1-21 
TR, network abbreviation in file 
name 6-5 
trace file 
—captured frames 2-54, 5-68 
—delete 5-70 
—end of file record 6-21 
—format 6-19 
—header 6-20 
—identifying extension 6-5 
—load 5-3 
—name 6-10 


—source of capture 1-8, 2-3, 2-49, 
2-54 


T sea a ; —version record 6-20 
—unit, field in trace file 6-20, 6-21 ; 
: ; trace tool present, token ring mes- 
T time-domain reflectometer 3-3 sage 1-5 
—suffix in extension of f -t : 
pare ” ension of frame-type time-out traffic 
tiger frame flag 2-26, 5-20 Rs console and server —capture 1-8 
—counters during capture 2-4 
Tabi keg a -38 timestamp —density 1-10 is 
See one skyline to anoth- —captured frame 1-8 bar graph 1-10, 2-4, 2-43, 2-48 
—playback 1-8 maximum 2-43 
—move to next panel 5-39 : 3 
— title, printed report 5-56 scale 2-41 
s : —tabulation by source and desti- 
—byte rather than packet-oriented te ail siatiGie, Bien Gplans-? nation Ll, 2-44 
2-38 to frame n, range printed 5-52 total 312 
—example 5-24 token ring —volume 
—IP protocol number 2-29 —address recognized bits 5-32 skyline 2-48 
—-port in pattern match 2-23 —fragmented or beaconing 2-6 traffic generator 1-4, 4-3 
—protocol interpretation 1-21 —frame copied 5-32 
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—bar graph of transmission rate 
4-10 


—cause of time-out 4-3 
—delay between frames 4-6 
—diagram 1-7 
—frame content 4-11 
—frame size 4-5 
—sequence number 4-12 
—set up 44 
trailer, token ring 5-32 
transfer, file 7-4 


transliteration 
—ASCI or EBCDIC 5-33, 5-35 
—character data 5-34 
—dynamic choice of ASCII or EB- 

CDIC 5-35 

transmission order 
—bits within byte 5-27, 6-18 
—variation by network 5-27 


transport channel 
—analyzer observes self 1-5 


transport layer 
—ISO protocol interpretation 1-21 
—OSI model 5-33 


TRC, extension for file of captured 
frames 6-5, 6-10 


TRD, extension for file of station 
names 5-66, 6—5 


tree structure of menus 1-25 


TRI, extension for file of manufac- 
turer IDs 6-5, 6-17 


trigger 
—capture 2-5 


—diagram 1-7 
—event 1-12, 2-33 
—example 
ARCNET 2-36 
Ethernet 2-36 
token ring 2-36 
—flag 2-36, 5-21 
—jump to 5-38, 5-39 
—pattern 1-12, 2-5, 2-20 


—position in capture buffer 2-33, 
2-34 


—procedure to set 2-34 
—saved setup 5-71, 5-72 
—stop capture 1-12, 2-34, 2-53 


—when and how to stop capture 
2-33 


TRIGGERED (message) 2-33, 2-36 
TRLR, protocol filter 2-19 


TRLR, protocol interpretation 1-21 


TRS, extension for file of setup spec- 
ifications 5-71, 6-5, 6-12 


TRSNIFF, directory 6-8, 6-11 
truncation 
—effect 2-38 
—effect on spanned frame 2-38 
—frame 2-3, 2-5 
—stored frame 2-37 
TRW, manufacturer code 6-18 
two viewports 1-17, 5-4, 5-15 
two-station format 1-17, 5-18 
—choice of stations 5-19 
—display of other frames 5-19 
—example 5-18 
—hints for adjustment 5-19 
—source and destination 5-18 
—summary view 5-18 


TxC, synchronous line status indica- 
tor 2-43, 2-47 


TxD, synchronous line status indica- 
tor 2-43, 2-47 


TXT, file extension for text 6-4 
type 
—address 5-63 


—-station address in name table 
6-15 


U 
UA, HDLC type 2-47 
U-B 
—manufacturer code 6-18 
—protocol filter 2-19 
UDP, protocol interpretation 1-21 
UL, in generated frame 4-11 
unexpected protocol 544 
unique address, name table 5-64 
Unisys, manufacturer code 6-18 


units 
—capture display 2-5 
—counters,totals, skylines, density 
bar graph 2-40 
—traffic density during capture 
2-39 
Univation, manufacturer code 6-18 
unknown station 
—effect of name table 2-12 
—filter 1-9, 2-5, 2-11, 2-12 
—name table 2-9 


up arrow: see cursor up 
upstream neighbor, token ring 5-32 
utilization 

—capture buffer 2-43 

—percentage 2-5 

—summary view 5-20 


V 
validity checks 5-32 
version, field in trace file 6-19, 6-20 
view 
—active 5-15 
—captured frames 1-12 
—detail 1-16, 5-15, 5-23, 5-25 
—earlier/later (skyline) 2-48 
—hexadecimal 1-16, 5-15, 5-33 
—position of summary, detail, hex 
5-15 
—scrolling 5-35 
—several on screen 5-25 
—summary 1-16, 5-14, 5-15 
—summary, detail, hex 1-15 


viewport 1-17 
—side by side 5-15 
VINES, bit-level interpretation 5-29 


VINES, protocol interpreter suite 
1-21 


VIP, example of bit-level interpreta- 
tion 5-29 


Visual Technology, manufacturer 
code 6-18 


Vitalink, manufacturer code 6-18 
VTP, protocol interpretation 1-21 


W 


WAN 
—capture filter 2-5 
—NRZ vs. NRZI 2-9 


WAN/synchronous 
—capture example 2-47 
—line status display 2-43 
—network code in trace file 6-20 
—options 2-8 

well known port 2-23 

Wellfleet, manufacturer code 6-18 


Western Digital, manufacturer code 
6-18 


whole frame, capture option 2-37 
width 
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—name 5-16 Z 
asthe eieplayeo-20 ZIP, protocol interpretation 1-21 
wild card character in pattern match ZNet, network code in trace file 6-20 
2-22, 2-25 
, zoom 
window 


—active panel 1-18, 5-38 


—as part of display: see panel —fanctton key 5-15, 3-98 


—specify size for network utiliza- 
tion 5-22 


working name table, contrast with 
saved file 5-64 


X 


X Windows 
—interpreter suite in configuration 
utility example 7-5 
—protocol 
spanned frames 2-38 
—protocol interpreter suite 1-21 
X, don’t care character in pattern 
match 2-22, 2-25 
X.25 
—count during capture 2-46, 2-47 
—layer 3 
protocol interpretation 1-21 
—LCN 2-47 
—protocol interpreter suite 1-21 
—WAN/synchronous option 2-8 
X.28, protocol interpretation 1-21 
X.29, protocol interpretation 1-21 
X.3, protocol interpretation 1-21 
X.400 
—address level 5~7 
—protocol interpretation 1-21 
—syntactic vs. semantic interpreta- 
tion 5-30 
Xerox, manufacturer code 6-18 
XNS 
—address level 5-7 
—level in name table 5-11 
—protocol filter 2-19 
—protocol interpretation 1-21 
—protocol interpreter suite 1-21 
—protocol suite example 2-36 
xxSNIFF, directory 6-8 
Xyplex, manufacturer code 6-18 


Xyvision, manufacturer code 6-18 


¥ 


YP (Yellow Pages), protocol inter- 
pretation 1-21 
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